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I.  INTRODUCTION 


1.  GENERAL 

This  final  technical  report  documents  the  results  oi  the  Knowledge  Based  Multi-Level 
Secure  Network  Technology  (KBMLSNT)  project  The  document  details  all  technical  work 
accomplished  and  information  gained  in  the  perfcmnance  of  the  contract  The  document  describes 
the  demonstration  ctf  artificial  intelligence  techniques  to  perform  identification  and  sanitization  of 
sensitive  information  for  dissemination  to  tactical  battlefield  cmnmanders. 

2.  BACKGROUND 

Intelligence  information  acquired  throu^  sophisticated  sensOTs  are  critical  inputs  to  the 
tactical  commanders  decision  process.  Tactical  commanders  in  the  field  require  this  real-time 
intelligence  support  but  do  not  need  to  know  the  source  of  that  data,  nor  do  they  have  the  means 
to  protect  its  highly  classified  nature.  The  sanitization  of  classified  data  can  be  employed  to 
permit  wider  distribution  of  essential  intelligence  information  while  protecting  die  sensitive  source 
of  that  information.  Manual  saititization  is  a  time  consuming  process  which  may  delay  the 
expeditious  processing  and  dissemination  of  intelligence  information.  Automation  of  the 
sanitization  process  could  sigiuficantly  in^rove  the  timely  dissemination  of  critical  information  to 
battlefield  commanders  thereby  improving  the  preparedness  of  fwward  area  deployed  forces. 

Current  sanitization  methods  require  that  analysts  identify  sensitive  intelligence 
information  and  determine  through  clearly  established  procedures  how  that  data  can  be  sanitized. 
Once  sanitized,  the  analyst  must  write  or  reformat  the  releasable  information  into  a  properly 
formatted  message  fcH*  dissemination  to  tactical  battlefield  commanders. 

In  a  dynamic,  active  threat  environment,  there  can  be  an  order  of  magnitude  increase  in  the 
volume  of  critical,  intelligence  derived  information.  During  these  high  tempo  qperations,  human 
sanitization  would  likely  result  in  the  delay  or  loss  of  information  required  by  tactical 
commanders.  As  the  volume  of  intelligence  data  increases,  there  exists  the  potential  for  a 
correspcMiding  increase  in  inadvertent  security  breaches,  critical  infcmnation  gaps,  and  lengthy 
delays  in  the  delivery  of  critical  information  to  tactical  commanders. 

3.  OBJECTIVE 

The  objective  of  this  project  was  to  define  and  develop  a  knowledge  based  multi-level 
secure  network  interface  that  will  increase  the  flow  of  critical  Command,  Control, 
Communications,  and  Intelligence  (C3I)  information  to  the  tactical  battlefield  commander. 
Specifically,  the  efforts  were  to  assess  the  feasibility  of  applying  artificial  intelligence  techniques 
to  assist  the  intelligence  analyst  in  the  satutization  of  classified  information  from  one  classification 
level  to  a  lower  classification  level,  eventually  automating  the  sanitization  process.  The  target 
product  is  an  implementation  of  a  sanitization  model  which  utilizes  commercial  off-the-shelf 
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software  packages,  tranq;x»table  and  is  complainant  with  government  and  industry  standards. 

4.  APPROACH 

The  approach  was  to  define  the  manurd  sanitization  procedures  with  sufficient  clarity  to 
initially  develop  a  model  and  then  implement  the  model  as  a  ccMnputer  software.  The  first 
research  task  was  to  condua  an  analysis  of  existing  manual  sanitization  procedures  at  a  site  whoe 
those  rules,  procedures,  patterns,  and  information  structures  could  be  readily  <d)tained.  This 
analysis  would  result  in  the  definition  of  a  sanitization  model  The  second  research  task  focused 
on  identifying  available  commercial  off-the-shelf  technology  which  could  be  ^rplied  to  the 
implementation  of  the  model.  Both  expert  system  mols  and  natural  language  tools  were  surveyed. 
The  third  task  was  to  develop  a  design  for  a  computer  based  architecture  for  implementing  the 
nxxlel  and  proceed  with  implementation  of  the  model.  The  design  maximizes  the  use  of  (X)TS 
software.  The  final  task  was  to  demonstrate  the  sanitization  of  fmmatted  message  traffic. 
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n.  RESULTS 


1.  GENERAL 

The  work  accomplished  three  tasks:  analyas  ci  sanitizatum  procedures  and  developrooit 
of  a  sanitization  mod^l;  survey  of  AI  technologies  including  expert  systems  and  natural  language 
processors;  and  implementation  of  the  sanitization  model  resulting  in  a  feasibility  demonstration. 
The  denaonstration  was  to  show  how  sanitization  of  sensitive  compartmented  information  can  be 
accomplished  with  Expert  Systems  conjurer  software. 

The  fcdlowing  sections  describes  the  acctxsplishments  and  results  in  detail  Sectkxi2 
presents  the  re«ilts  oi  an  on-site  analysis  of  manual  sanitization  procedures,  conducted  at  USAFE 
facilities.  Section  3  presents  the  results  from  surveys  document  parsing  and  expert  system 
toob.  Seetkm  4  presents  the  design  of  an  expert  system  based  sanitization  prototype.  Section  5 
presents  a  summary  of  all  preliminary  and  formal  testing.  Section  6  presents  an  approach  to 
implementation  with  a  concept  t^teradon. 

2.  ANALYSIS  RESULTS 

A  feasibility  analysis  was  conducted  at  the  United  States  Air  Force  Headquarters  in 
Europe  (USAFE)  and  Allied/NATO  facilities  in  the  German  Democratic  Republic  in  November  of 
1989  and  May  of  1990.  The  analysis  focused  on  determining  whether  the  process  of  sanitizing 
information  acquired  throu^  highly  sensitive  intelligence  sources  can  be  specified  with  sufficient 
clarity  to  initially  assist  and  ultimately  replace  the  manual  operator  and  if  such  specificity  is 
possible  to  develop  a  multi  level  secure  sanitization  model 

The  analysis  of  existing  manual  sanitization  irocedures  is  the  crucial  first  stq>  in 
developing  an  automated  iq>proach  to  initially  assisting  and  eventually  automating  the  intelligence 
analyst  function  of  identifying  and  sanitizing  critical  intelligence  information.  This  effort  identified 
rules,  procedures,  patterns,  and  information  structures  which  compose  the  manual  sanitization 
process  and  the  development  of  a  model  which  reflects  the  manual  sanitization  process. 

An  iterative  development  approach  was  used  which  incorporates  end-users'  operational 
experiences  through  a  structured  review/enhancement  cycle,  yielding  the  real-world  model.  A 
team  of  senior  engineers  were  tasked:  to  analyze  manual  sanitization  procedures  and  if  feasible  to 
develop  an  sanitization  model  FSC  engineers  identified,  studied  and  documented  analyst's 
procedures  and  techniques  which  pertained  to  sanitization.  The  following  approach  was  taken: 

•  Examine  National,  Service,  and  Theater  level  documentation  to  obtain  a  textbook 
definition  for  a  sanitization  model  and  to  develop  a  list  of  questions  for  site  intelligence 
analysts  to  answer. 
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Gmerate  a  textbook  sanitization  niodel  and  questioning  scheme  to  be  used  during  the 
on-site  data  gathering  knowledge  acquisition  |»ocess. 


Interact  with  site  intelligence  analysts  to  record  real-woiid  procedures  which  alSect  the 
model's  definition. 


•  Integrate  analyst's  thoughts  into  the  model. 

2.1  Site  Survey 

An  analysis  of  the  Combat  Operations  Intelligence  Center  (COIQ,  Ramstein  AFB,  West 
Germany  and  the  Tactical  Fusion  Center  (TFC),  Boerfink,  West  Germany  determined  diat  the 
sanitization  process  can  be  specified  with  efficient  clarity  to  initially  assist  and  ultimately  replace 
the  manual  operator. 

2.1.1  US  AFE  Combat  Operations  Intelligence  Center  (COIQ 

The  COIC  is  divided  into  several  functional  intelligence  areas  charged  with  developing 
situation  summaries,  briefings  or  other  repents  by  assimilating  intelligence  data  with  datalrase 
information  (order  of  batde  files,  commander's  operation  plansAasldng  enders,  enemy  doctrine). 
These  repents  are  then  used  by  the  reconnaissance  retaskers  to  eiirect  sensen*  sources  to  the  tactical 
areas  of  interest  This  provides  the  me>st  cunent  intelligence  picture  fen*  the  near-real-time 
targeteer  to  use  to  prepare  strike  plans  against  mobile  and  fixed  targets. 

Although  the  COIC  does  generate  classified  information,  it  does  not  have  a  con^hensive 
NATO  reporting  requirement  as  part  of  its  mission.  Discussions  with  several  analysts  suggests 
that  the  sanidzaticni  function  for  the  NATO  consumers  is  rarely  performed  at  the  COIC.  For  the 
most  part,  historical  and  background  information  is  maintained  in  harda^y  reports  and  messages. 

2. 1 .2  US  AFE  Tactical  Fusion  Center  (TFC) 

The  TFC  is  divided  into  the  Warning  Branch  and  the  Force  Assessment  Branch.  The 
Warning  Branch  ctxisist  of  watch  standing  personnel  that  are  divided  into  three  Indications  and 
Warning  (I&W)  teams  to  provide  around  the  clock  real-time  suppext  to  NATO.  The  Force 
Assessment  (FA)  Branch  is  comprised  of  day  working  support  personnel  that  provide  support  to 
the  I&W  teams,  and  perfoim  various  other  functions  such  as;  data  base  maintenance  for  the  Air 
Order  of  Battle  (AOB),  the  Surface-to-Air  (SAM)  Missile-Order-of-battle  (MOB),  and  ad  hoc 
analysis  and  reporting  functions. 
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The  TFC  lecdves  inteUigenoe  infonottxm  firom  a  vai^  of  soiBces  and  soiian  vk  reo^ 
message  traffic.  These  messages  include: 

•  NARRATIVE  SPOT  REPORTS 

•  NARRATIVE  E-GRAM  REPORTS 

•  OTHER  NARRATIVE  REPORTS 

•  FORMATTED  IMAGERY  REPORTS 

•  FORMATTED  TACTICAL  REPORTS 

•  FORMATTED  TACTICAL  EUNT  REPORTS 

•  FORMATTED  OPERATIONAL  EUNT  REPORTS. 

A  number  of  the  above  message  types  are  received  with  a  classification  line  vdiidi  allows 
automatic  release  to  NATO  consumers  without  additional  analyst  interventitm.  Odiers  require 
analysis,  evaluation,  and  editing  prior  to  being  considered  for  release  to  the  NATO  communi^. 
The  TFC  produces  the  following  intelligence  products  to  various  consumers: 

•  SAM  OOB  for  NATO 

•  USAFE  AOB 

•  Fused  Intelligence  Repcvt  to  Europe  (FIRE) 

•  TFC  Intelligence  Input  to  NATO  (TTIN) 

•  TFC  Wartime  Intelligence  Input  to  NATO  (TWIIN)  -  Wartime  Only 

•  SAM  Intelligence  Report  (S  AMINTREP) 

•  Intelligence  Report  (INTREP) 

•  Target  Air  Nomination  (TAN)  -  Wartime  Only 
(a  hardcopy  document  produced  yearly). 

The  following  events  or  activities  are  routinely  repented  by  TFC  analysts:  forward  weather 
conditions,  selected  border  and/or  air  corridor  violations,  selected  air  defense  exercises,  instances 
of  communist  block  active  Electronic  Counter  Measures  (ECM),  selected  n(x>bility  training 
exocises,  selected  deployment  operations,  Missile-Qrder-of-battle  (MOB)  information, 
intelligence  collection  flights  and  forward  area  penetrations  by  Soviet  bombers,  selected  ground 
support  exercises/operations,  instances  of  live  missile  firings,  and  any  other  significant  air  or 
ground  activity. 

The  TFC  analyst  uses  a  two  step  approach  to  determining  if  a  message  is  releasable  to 
NATO.  The  first  step  is  to  check  fcnmal  DOD,  USAF,  and  locally  generated  procedures  that 
establish  well  defined  rules  and  guidelines  for  release  of  information  to  NATO.  The  setxxid  step 
is  to  make  a  decision,  or  request  assistance  in  making  a  decision  based  on  the  sensitivity  of  the 
information,  the  impoitance/need  of  the  information  and  suitable  cover  for  the  infoimation.  To 
accomplish  this,  tiie  TFC  analyst  will  eitiier  sanitize  or  decompartment  the  information  at  the  TFC 
and  release  that  information  to  NATO.  For  this  purpose,  tiie  following  definititnis  iq)ply: 
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•  Sanitizadoa  -  The  process  (rf  editing  or  otherwise  altering  intelligence  to  protect 
sensitive  sources,  methods  or  analytical  capabilities  so  as  to  permit  greater  dissemination 
of  the  information.  Sanitization  is  not  to  be  confused  with  "Declassification  or 
Downgrading".  A  sanitized  "SECRET"  reptnt  is  stiU  classified  "SECRET*  after  the 
sanitizaticMi  process  has  taken  place. 

•  Decompaitmentation  <  The  removal  (tf  information  from  a  compaitmentation  system 
without  altering  the  information  to  conceal  sources,  methods  or  analytical  procedures. 
Normally,  dectnupartmented  intelligence  products  must  contain  certain  control  markings 
that  restrict  dissemination  to  US.  chaiuiels  only. 

•  Release  >  The  physical  or  electronic  transfer  of  intelligence  products  to  an  authtHized 
recipient 

In  supporting  NATO  customers,  the  TFC  sanitizes  information  to  the  SECRET  level  and 
below.  In  general  two  intelligence  disciplines  are  affected  by  this  sanitization  process;  Signal 
Intelligence  (SIGINT)  and  Imagery  Intelligence  (IMINT).  Each  discipline  presents  unique 
sanitization  considerations  for  the  reporting  TFC  analyst 

Locally  generated  Operating  Instructions  (OIs)  provide  the  analyst  a  baseline  from  which  a 
sanitization  decision  can  usually  be  made.  However,  situations  may  arise  that  are  not  addressed 
by  existing  OIs  and  the  analyst  must  then  rely  on  two  key  considerations  of  sanitization;  1) 
sensitivity  of  the  informatim  involved  and  2)  the  intelligence  needs  of  the  NATO  recipients.  Due 
to  the  nature  of  the  information  and  processes  involved,  the  rules  governing  sanitization  are 
themselves  classified  and  are  not  included  in  this  repeat 

2.1.3  Survey  Ccxiclusion 

The  operational  mission  of  the  COIC  as  determined  thixaigh  our  on  site  visit  suggests  that 
the  COIC  not  be  considered  as  a  candidate  for  modeling  of  the  sanitization  process.  The  mission 
of  the  TFC  and  tiie  established  well  described  and  tightly  constrained  process  of  preparing 
messages  fcH-  release  to  NATO  indicates  the  greater  potential  for  modeling  the  manual  sanitization 
process. 

2.2  Sanitization  Model  Definition 

The  Sanitization  noodel  documents  the  manual  sanitization  process  performed  by 
intelligence  analysts  at  the  Tactical  Fusion  Center  when  providing  timely  intelligence  information 
to  Tactical  Battlefield  Commanders.  The  model  specifically  concentrates  cm  tasks  which  analysts 
perform  during  saititization  of  sensitive  information.  The  model  takes  into  account  the  knowledge 
which  analysts  acquire  during  the  process  and  suggests  an  organization  of  that  knowledge. 
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2.2.1  Model  Summary. 


The  model  encompasses  four  primary  tasks;  Identification,  Associatkm,  Sanitization,  and 
Dissemination.  Figure  2.2.1-1  depicts  a  decision  flow  of  the  Sarutization  model.  At  each  task 
information  known  as  sanitization  knowledge  is  accessed,  collected,  and  cnrganized  into  a 
sarutization  knowledge-base. 


The  Identification  task  identifies  messages  and  other  intelligence  information  into  Three 
general  categories; 

1 .  Infcxmation  of  no  interest  to  supported  commanders.  This  infonnation  is  purged  from  the 
system  with  no  further  action. 

2.  Information  of  interest  to  supported  commanders.  This  information  is  disseminated 
without  further  processing. 

3.  InfOTmation  of  interest  to  the  supported  commanders  that  is  classified  SCI  and  is  not 
releasable  in  its  current  form  and  needs  to  be  considered  for  sanitization. 

The  Association  task  relates  incoming  messages  and  other  intelligence  infotmaticm  to 
existing  intelligence  information.  Duplicate  information  is  purged  from  the  systeno. 

The  Sanitization  task  t^plies  sanitization  rules  to  separate  messages  and  other  intelligence 
information  of  interest  to  supported  commanders  into  either  informaticxi  which  can  not  be 
sanitized  or  information  which  can  be  saititized.  Information  which  can  not  be  sanitized  under  any 
circumstances  is  stored  in  an  SCI  data  base  and  used  to  support  further  analysis.  Information 
which  can  be  sanitized  is  processed  by  the  analyst  to  produce  an  appropriately  classified  collateral 
(non-SCI)  product  for  dissemination  to  the  commanders. 
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Dissemination  is  the  final  task  in  the  model  and  invedves  the  review  and  release  of 
collateral  (non-SQ)  products  to  supported  commanders. 

The  Sanitization  mcdel,  a  sanitization  knowledge  base  which  retains  the  expoience  and 
education  of  analysts.  Hgure2.2.1-2  depicts  the  sanitization  knowledge  base.  Knowledge  is 
divided  into  infcmnadon  about  die  message,  related  intelligence  infonnatkxi.  and  informatkHi 
pertaining  to  sanitization.  S<Hne  knowledge  is  temporary,  while  other  knowledge  will  linger  and 
remain  within  the  knowledge  base  analogous  to  die  human's  eiqierience  and  education.  It  is 
referenced  again  and  again  while  processing  messages  and  other  intelligence  informatiexL 


1  KBM 

r  .  . 

1— j  Messi^  InformatioB  J 

- [M^geJ 

1  Abstract  of  facts  I 

■  H  Relevancy  A  Imooftance  Indicators! 

Reference  Infonnatjon] 

- — !  Messases  References  1 

'  '  \  Data  Base  References  1 

'  ■  '  1  Recent  Intellieence  Information  1 

H  Sanitization  Information  1  1 

■  1  Sanitized  Nanativd 

■"  !  Sanitized  DB  Update  Record  I 

FIGURE  2.2. 1-2.  Sanitization  Knowledge  Base 
2.2.2  Model  Description. 

This  section  identifies  and  describes  the  tasks,  functions  and  procedures  with  the 
Sanitization  Model.  Each  task  is  presented  with  a  description  of  its  purpose  and  processing  flow. 
In  addition,  a  description  of  the  specific  knowledge  acquired  in  each  task  during  the  manual 
sanitization  process  is  documented. 
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2.2.2. 1  Identification 


The  purpose  of  the  Identification  task  is  to  recognize  infonnation  of  interest  to  tactical 
battlefield  conamanders  and  identify  candidates  for  sanitization.  This  screening  procedure, 
perfcHnoed  by  analysts,  determines  the  degree  of  relevancy  and  importance  of  tins  data  to  tactical 
battlefield  commanders.  Figure  2.2.2- 1  depicts  the  Identification  task  functions  and  flow. 


FIGURE  2.2.2- 1  Identificaticxi  Task  Functional  Flow 

Incoming  messages  are  reviewed  for  subject  and  classificatitxi  by  the  Message 
Identification  function.  The  message  header  contains  the  source,  classification,  and  priority.  The 
body  of  the  message  contains  the  answers  to  the  questions:  WHO  (object),  WHAT  (activity), 
WHERE  (location),  WHY  (history),  WHEN  (time),  and  HOW  (history).  The  Interest  Screening 
function  identifies  wing  commanc^  which  are  interested  in  the  infonnation.  The  Message 
Assessment  function  determines  die  processing  flow  for  the  remainder  of  the  model  Messages 
which  contain  informatitxi  of  little  value  to  the  analyst  are  set  aside  and  referenced  in  the  future  as 
recent  intelligence  infermation.  Messages  of  high  interest  which  already  satisfy  releasable  criteria 
are  candidates  for  the  Dissemination  Task.  High  interest  sensitive  information  which  do  not  meet 
initial  release  criteria  require  sanitization  and  must  proceed  to  the  next  step,  the  Association  task. 

2.2.2.2  Association 

The  purpose  of  the  Association  task  is  to  establish  links  to  all  relevant  information. 

Figure  2.2.2-2  depicts  the  Association  task  functions  and  flow. 


FIGURE  2.2.2-2  Association  Task  Functional  Flow 
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The  Nfessage  Refeience  Check  function  reviews  message  queues  fra:  related  inftxmation. 
The  Data  Base  Reference  Check  function  reviews  Order-of-Battle  Data  Bases.  Missile-Onier-of- 
Battle  (MOB)  and  Air-Order-of-Battle  (AOB)  data  bases  are  examined  to  obtain  the  latest 
infcxmation  on  ht^tile  air  wings  and  surface-to-air  missiles.  The  Recent  Reference  Check 
function  reviews  information  which  for  one  reason  ch*  another  was  not  capable  of  being  sanitizet* 

2.2.2.3  Sanitization 

The  purpose  of  the  Sanitization  task  is  to  sanitize  compartmental  infcamation  by 
implementing  specific  sanitization  procedures.  Sanitization  consists  of  two  separate  activities. 
The  first  activity  is  to  determine  if  the  information  can  be  saiutized.  Activities  are;  (1)  determine 
why  the  information  is  SQ,  (2)  determine  if  information  can  be  sanitized  under  existing  criteria, 
(3)  (fetetmine  if  operational  situation  meets  sanitization  criteria,  (4)  determine  if  required 
additicMial  information  meets  criteria,  and  (5)  select  appropriate  sanitization  procedure.  The 
second  activity  is  the  actual  sanitization  of  the  SCI  information.  Here  is  where  the  infcmnation  is 
removed,  disguised,  or  merged  with  less  sensitive  information  to  create  a  releasable  product 
Hgiue  2.2.2-3  depicts  the  Sanitization  task  functions  and  flow. 


FIGURE  2.2.2-3  Sanitization  Task  Functional  Flow 

The  Less  Sensitive  Source  check  attempts  to  find  another  messages  which  are  less 
sensitive.  The  Plausible  Clover  function  is  where  suitable  coverage  or  reasonable  coverage.  The 
Sanitization  Justification  function  contains  a  set  of  rules  which  determine  if  infcxmation  can  be 
sanitized  and  to  what  degree.  The  determination  is  based  on  rules  derived  fixxn  National,  Service, 
Theater,  and  site  specific  manuals.  The  Message  Sanitizatitxi  function  relies  on  sanitization 
instructitxis  to  minimize  the  risk  of  possible  compromise  of  source,  methods,  techiuques,  and/or 
degree  of  success.  Each  message  which  is  received  by  the  site  has  a  set  of  modifiable  instructions 
which  address  methods  for  sarutization. 

2.2.2.4  Dissemination 

The  purpose  of  the  Dissemination  task  is  to  review  and  release  the  sanitized  information. 
This  task  generates  the  proper  message  and  reviews  the  message  for  release.  Figure  2.2.2-4 
depicts  the  Dissemination  task  functions  and  flow. 
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FIGURE  2^.2-4  Dissemination  Task  FunctkMud  Flow 


The  Nfessage  Creation  function  is  the  genoation  and  editing  of  sanitiMd  messages.  The 
Review/Release  functions  is  a  security  check  performed  on  all  outgoing  messages  inior  to  release. 
The  message  is  reviewed  for  sensitive  words  oc  phrases  which  might  expose  the  source,  method, 
or  technique  which  was  used  to  acquire  this  information.  The  review  is  perfcmiied  to  ensure  that 
die  sanitized  information  implements  the  approved  security  policy. 

2.3  Conclusions 

2.3. 1  Current  Sanitization  Process  verses  the  Sanitization  Model 

The  current  manual  process  for  extracting  infcnmatimi  received  from  sensitive  sources  and 
fcH’  making  changes  to  such  information  in  order  to  make  it  eligiUe  for  release  to  users  was 
coooqiared  to  the  sanitization  model  described  in  the  sectitm.  llie  SanitizatuMi  Model  was  found 
to  be  accurate  in  its  description  of  all  major  functions  and  in  its  triplication  of  guidelines  and 
standard  operating  procedures  of  the  National,  Theater,  and  local  security  regulaticms.  The  model 
was  discussed  with  analysts  who  routinely  perform  the  sanitization.  The  consensus  among  those 
who  reviewed  the  nxxlel  is  that  it  quite  accurately  represents  the  manual  process  and  that  it 
accounts  for  all  the  major  factors  involved  in  making  the  sanitization  decisions. 

2.3.2  Qosing  Summary 

The  feasibility  analysis  detailed  the  manual  sanitizatitxi  procedures  used  in  tiie  USAFE 
Tactical  Fusion  Center  and  developed  an  information  flow  model  to  use  for  further  analysis. 

The  analysis  to  date  shows  a  very  high  potential  fcx*  developing  Artificial  Intelligence  techniques 
to  bring  significant  automation  to  the  sanitization  process  with  no  increase  in  security 
vulnerability.  Using  the  defined  model  it  was  shown  that  at  every  major  point  in  the  process,  the 
activities  can  be  specified  with  sufficient  clarity  and  control  to  develq)  a  ctxnputer  program 
assist  the  operator  in  assembling  and  analyzing  the  information  and  the  rules  whkh  govern  its 
releasabUity.  As  a  minimum,  a  rule  oriented  (Expert  System)  Data  Base  Management  System 
seems  very  feasible  as  a  means  to  assist  the  analysts  in  linking  past  messages  to  current 
sanitization  issues.  The  DBMS  could  provide  the  basis  for  further  automatkm  such  as  key 
situation  assessment  through  pattern  analysis  techniques.  At  every  stage  in  the  irxxiel,  there  is  at 
least  the  potential  to  make  the  analyst's  effort  more  productive  and  less  error  prone  through  the 
use  of  expert  systems  techniques.  At  several  points,  it  may  be  possible  to  achieve  a  coo^letely 
automatic  function  that  generates  a  product  for  an  operator  to  approve.  Building  on  a  protoQq)e 
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which  starts  out  with  basic  AI  c^Mlalities  like  the  ones  described  above,  it  appears  at  teast 
leasooaUy  feasSde  to  increase  its  performance  and  security  trustworthiness  to  the  p(^  drat  it 
could  perform  the  sanitization  without  c^retator  intervention. 

3.  SURVEY  RESULTS 

3.1  Overview 

During  the  architecture  development  phase  of  the  KBMLS  prototype,  ^recified  and 
derived  functicnial,  performance  and  supportability  requirements  were  allocated  to  syston 
software  and  hardware  components.  Based  upon  these  requirements,  and  Ixised  up<xi  the 
sanirizarinn  model  architecture  of  the  KBMLS  prototype,  criteria  were  derived  for  evaluating 
GOTS/CXyrS  software  tools  which  could  satisfy  the  allocated  requirements.  The  approach  taken 
in  conducting  this  survey  included  the  following  objectives: 

•  Define  and  establish  the  criteria  to  be  used  in  evaluating  and  selecting  a^ppropriate 
parsing  and  expert  system  tools 

•  Obtain  general  information  on  as  many  tools  of  each  category  as  possible 

•  Reduce  the  saix^le  population  to  those  GOTS/COTS  tools  which  could  provide  the 
allocated  document  parsing  and  knowledge  representation  requirements  of  the  KBMLS 
prototype  architecture 

•  Evaluate  the  population  subset  based  on  a  tool's  ability  to  meet  the  established  criteria 

•  Identify  those  tools  most  capable  of  providing  the  necessary  parsing/expert  system 
functionality  based  cm  the  specified  criteria. 

General  information  was  solicited  brom  numoous  vendors  of  document  parsing  tools  and 
expert  systems.  Appendix  A  lists  the  evaluated  tool  population  for  expert  systems  and  provides  a 
brief  description  of  sane  of  the  basic  features  of  the  twenty-five  tools  which  were  initially 
considered  in  the  survey.  Appendix  B  provides  information  on  the  evaluated  document  parsing 
tools. 


Based  (m  a  comparison  of  the  sample  tool  population  features  with  the  established 
evaluation  criteria,  KES  (Software  A&E)  is  recommended  as  the  KBMLS  expert  system  shell. 
KES  provides  the  richest  set  of  expert  system  features,  is  available  wi  a  larger  number  of  host 
platforms,  and  has  a  software  architecture  which  facilitates  integration  with  other  KBMLS 
applications. 

The  preliminary  analysis  and  evaluation  of  document  parsing  tools  showed  a  diverse  range 
of  capabilities  and  functions  which  made  a  direct  comparison  of  features  difficult  The  survey  was 
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unaUe  to  identify  any  document  parsing  tocds  whkh  specifically  meet  all  of  the  lequiiemmts  of 
die  KBMLS  prototype.  Most  commercially  available  tools  which  satisfied  a  subset  oi  the  required 
technical  and  functional  features  could  be  categtxized  as  natural  language  processing  and 
textAnfcmnation  retrieval  systems.  None  of  these  tools  were  specifically  engineered  as  "document 
parsing"  tools.  As  a  result,  each  failed  to  satisfy  many  of  die  KBMLS  prototype  requirements. 
However,  of  those  tools  surveyed,  NL  Builder  (Sychrcmetics,  Inc.)  provides  acceptable 
functionality  and  an  architecture  that  permits  limited  integration  within  the  KBMLS  prototype. 

The  results  of  the  survey  are  based  on  literature  reviews,  intfependent  evaluatkxis, 
discussions  widi  developers  of  fielded  systems,  vendor-supplied  materials,  and  write-ups  on 
fielded  systems  when  availaUe. 

3.2  Expert  System  Survey  Results 

The  following  subsections  summarize  the  evaluatimis,  draw  conclusions,  and  present  a 
recommendation. 

3.2.1.  Evaluations 

Of  25  expert  systems  identified,  five  were  selected  for  in-depth  evaluation  and  analysis: 
COSMIC  CLIPS  developed  by  the  National  Aeronautics  and  Space  Administration;  GURU 
developed  by  Micro  Data  Systems,  Inc.;  EXSYS  developed  by  Exsys  Corporation;  KES 
developed  by  Software  A&E,  Inc.;  and  NEXPERT  developed  by  Neuron  Data  Inc.  All  of  these 
tools  are  categcrized  as  expert  system  shells.  Each  of  the  five  shells  were  extensively  evaluated 
and  reviewed  against  the  survey  evaluation  criteria.  Table  3.2.1-1  summarizes  the  evaluatiem  of 
expert  system  characteristics. 

TABLE  3.2. 1  - 1  Expert  System  Evaluation  Chart 


NEXPERT 

CLIPS 

EXSYS 

GURU 

KES 

Power  & 
Flexibility 

9 

4 

6 

6 

9 

9 

8 

7 

5 

10 

System 

Interface 

9 

8 

5 

6 

9 

Vendor 

Evaluation 

9 

7 

9 

8 

10 

Total 

36 

27 

27 

25 

38 

Initial  evaluations  of  the  five  expert  system  (ES)  shells  revealed  that  each  possessed 
acceptable  developer  and  user  interfaces.  No  shell  provided  features  significantly  superior  to  the 
others  in  this  area.  In  general,  expert  system  shells,  as  opposed  to  AI  languages  such  as  LISP  and 
PROLOG,  have  been  specifically  engineered  to  provide  enhanced  develc^ier  and  user  interfaces  in 
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addition  to  providing  extensive  development  and  debugging  capabilities.  Each  shell's  develc^io’ 
interface,  user  interface,  development  capacity  and  debugging  capabilities  satisfied  the  established 
evaluation  criteria  for  develoixnent  and  implementation  of  the  I^MLS  prototype.  In  addition, 
each  of  the  five  tods  were  evaluated  as  having  acceptable  capabilities  ftH*  rapid  prototype 
development  and  iterative  refinement  of  their  knowledge  bases.  These  ct^iabilities  (i.e.  enhanced 
user/developer  interlaces  and  develt^mrat/debugging  capabilities)  were  the  primary  screening 
criteria  used  to  reduce  the  initial  twenty-five  tools  to  five  selected  for  further  evaluation. 

Technical  features  deemed  critical  to  the  KBMLS  prototype  devel(^)ment  are:  strength  of 
rule  representation  and  ease  of  rule  nKxlification  (power  and  flexibility);  availability  on  a  wide 
range  of  conventional  hardware  platforms  (portability);  and  the  ability  to  be  integrated  and 
embedded  within  other  conventionally  developed  applications  (system  interface).  Secondary 
desirable  features  important  to  both  the  rapid  development  and  future  evolution  oi  the  system, 
relate  to  the  tool's  acceptance  in  the  market  place  (i.e.  defacto  standards),  and  long-range  vendor 
stability  and  documentation/support  (vendor  evaluations).  Each  of  the  shells  were  rated  against 
these  criteria  and  the  resultant  ratings  were  used  in  the  final  selection  process.  Table  3.2. 1-2 
provides  the  rating  results.  A  dot  indicates  the  expert  system  has  the  capability. 
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TABLE  3^.1-2  Expen  System  Rating  Results 
KES  NEXPERT  EXSYS  CLIPS 


GURU 


Devdopment  & 
Userfaterikcc 


UunPacUi 


The  following  paragraphs  provide  a  brief  description  of  the  criteria  used  in  the  evaluation 
process  and  their  implications  for  the  KBMLSNI  demonstraticm  system.  Following  the  criteria 
descriptirxi  is  an  evaluation  of  the  capabilities  of  each  of  the  five  shells  in  relation  to  the  specified 
criteria. 


3.2. 1. 1  Power/Flexibility  oi  KB  Representadon  &  Inferencing 

Expert  system  shells  offer  many  differait  ways  to  represent  knowledge  as  well  as  many 
different  ways  to  reastni  with  the  knowledge.  Some  types  of  knowledge  representation  are  more 
naturally  suited  one  set  of  problem  domains  than  another.  In  evaluating  the  shells,  omsideration 
was  given  to  the  type  and  conq)lexity  of  knowledge  representation  and  reasoning  the  sanitizing 
problem  requires.  Each  of  the  shells  were  evaluated  with  respect  to  their  alnlity  to  encode  that 
knowled^  and  adequately  reason  (inference)  using  it  The  autcnnated  sanitization  process 
requires  that  the  selected  expert  system  shell  possess  a  very  powerful  knowledge  reptesentaticm 
scheme  and  inferencing  mechanism.  Simple  rule-based  tools  and  tools  representing  knowtedge  as 
context  trees  were  deemed  to  lack  sufficient  power  to  develop  the  sanitization  knowledge  base. 
The  nxxo  complete  methods  of  representing  knowledge  and  inferencing  found  in  hybrid  tools  was 
determined  to  be  {q)pr(^niate  fOT  ^  iy)plication. 

The  EXSYS  shell  is  classified  as  a  simple  rule-based  tooL  It  represents  knowledge  as 
rules  and  uses  a  backward  chaining  inference  engine  to  process  the  rules.  The  system  is  written  in 
the  C  language  and  is  noteworthy  for  its  speed  and  compactness  of  code.  EXSYS  represents 
facts  as  attribute- value  pairs  and  uses  if-then  rules  to  represent  relaticmships  between  facts.  The 
system  can  handle  approximately  7(X)  rules  per  64K  of  menxxy  and  can  process  an  unlimited 
number  of  rules  in  a  UNIX  environment 

NEXPERT  OBJECT  is  also  written  in  the  C  programming  language.  Its  inference  engine 
uses  both  forward  and  backward  chaining,  requires  4  Mbytes  of  menoory  and  runs  acceptably  fast 
on  Intel  80386  based  systems.  NEXPERT  is  advertised  as  a  hybrid  tool,  providing  a  number  of 
knowledge  representation  paradigms  as  well  as  a  number  of  complex  relationships  between  the 
knowledge.  An  independent  review  of  NEXPERT  OBJECT  indicated  that  this  shell  provides  only 
a  limited  iiiq)lementation  of  object-oriented  programming  and  it  lacks  the  message  passing 
features  needed  to  process  con^ilex  information  within  its  slots.  The  review  indicated  that  it  is 
better  to  view  this  shell  as  a  sophisticated,  structured,  rule-based  tool  that  allows  inheritance  in  an 
object-oriented  environment  versus  a  pure  hybrid  tool 

KES,  also  written  in  the  C  language,  has  been  designed  with  a  highly  modular  structure 
using  the  "information  hiding"  technique.  This  structure  has  allowed  KES  designers  to  break 
down  the  system  into  many  independent,  logical  units  or  modules.  The  shell  currently  supports  an 
extensive  set  of  knowledge  base  features  including;  Backward  and  forward  chaining,  object 
oriented  data  representation,  inheritance,  consistency  (truth)  maintenance  and  certainty  factors. 
KES  also  provides  three  types  of  inference  engines  which  increases  both  its  flexibility  and  power. 
The  three  inference  engines  are  the  Production  Rules  (PS),  Probability  and  Inference  (BAYES) 
and  the  Hypothesize  and  Test  (HT)  engine.  KES  PS  employs  production  rules  to  perform 
deductive  reasoning,  KES  BAYES  performs  statistical  pattern  classification  based  on  Bayes' 
theorem,  and  KES  HT  provides  a  higher  level  inference  engine  which  uses  deductive  reasoning. 
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COSMIC  CUPS  is  another  shell  writttti  in  C  The  devel(^>ers  erf  CUPS  designed  the 
shell  widi  the  goal  of  portability,  efiBciency  and  functionality.  CUPS  is  a  forward  chaining  rule- 
based  tool  which  is  based  on  the  Rete  algoithm.  The  collection  of  conditions  and  actions  to  be 
takan  if  rule  set  conditions  are  met  is  constructed  into  a  rule  netwexk.  While  the  tool  only  utilizes 
one  type  of  inferencing,  forward  chaining,  the  developers  of  CUPS  feel  that  this  limitation  is 
(rffset  by  the  conqrlexity  of  use  and  training  associated  with  hybrid  and  mexe  ccxi^licated  type  of 
inferoicing  tools.  Powerful  systems  have  been  built  using  single  paradigm  toc^  tmt  this  fact 
limits,  to  a  degree,  the  tool's  power  and  flexibility  of  inferencing  widi  the  knowledge  base. 

GURU  is  an  integrated  expert  system  development  environment,  containing  several 
different  types  of  coiiq)uter  processing  capabilities.  When  evaluating  the  GURU  expert  system 
shell  in  isolation  firom  the  test  of  GURU'S  develoi»nent  capabilities,  it  is  rated  as  a  simple  rule- 
based  system  which  represents  facts  and  rules  via  attrilxite-value  pairs.  GURU  relies  primarily  on 
backwi^  chaining  to  contrdi  its  reasoning.  Its  structure  centers  on  the  role  of  variables  in  the 
rule  base  with  the  variables  within  each  rule  set  forming  a  hierarchical  network  of  depenttencies 
obtain  their  values.  GURU  is  written  in  C.  The  primary  strengths  of  the  GURU  package  reside 
its  overall  integrated  environment  for  system  development 

3.2. 1.2  Portability/C(xiq)atibility 

FSCs  development  strategy  for  the  KBMLS  prototype  requires  long  term  maintainability 
and  portability  of  the  system  software.  Ptxtability  ensures  that  future  versions  of  the  KBMLS 
software  may  be  hosted  on  a  wide  range  of  hardware  platforms.  This  strategy  permits  a  relatively 
inexpensive  implementation  of  the  KBMLS  prototype  on  a  PC  based  computer  while  providing 
for  migration  to  higher  capacity  platforms  without  significant  software  development 

While  all  five  shells  are  written  in  the  C  programming  language,  wily  NEXPERT  OBJECT 
and  KES  specifically  emphasize  their  portal^ty  and  con^atil^ty  features.  The  KES  developer 
stresses  that  one  of  ^e  major  benefits  of  using  dieir  shell  was  its  modular  structure.  The  benefit 
of  the  KES  modular  structure  is  the  isolation  of  the  hardware  and  operating  dependencies  of  KES 
into  a  single,  easily  changeable  module.  As  a  result  KES  executes  on  mwe  hardware  platforms 
than  any  other  shell  surveyed. 

3.2. 1 .3  System  Interface  Capabilities 

A  major  specified  KBMLS  requirement  for  the  selected  expert  system  shell  is  the 
capability  to  provide  external  product  and  langua^  "bridges”.  An  effective  and  efficient  design  of 
the  automated  sanitization  process  requires  that  tiie  shell  also  possess  the  capability  to  be 
embedded  within  "convoitionally"  developed  applications  and  programs.  This  onbedding 
capabiliQr  will  allow  the  COTS  expert  system  to  be  invoked  as  a  subroutine  and  will  permit  a 
seamless  integratiwi  between  the  expert  system  shell  and  the  surrounding  layer  of  cwiventionally 
developed  software.  The  survey  criteria  includes  an  evaluation  of  expert  system  features  for 
embedded  integration  with  conventionally  deveic^}ed  applications  software.  This  criteria  is 
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essential  to  the  n^id  develt^mient  and  success  of  the  KBMLS  prototype. 

The  EXSYS  expert  system  shell  is  an  example  of  a  tool  that  permits  data  to  be  passed 
back  and  forth  for  analysis  but  lacks  an  integral  strucmre.  Data  is  passed  by  writing  it  to  a  disk 
file  which  EXSYS  then  reads.  External  programs  can  be  invoked  in  a  using  a  variety  of  methods 
with  data  passed  in  both  diiectimis.  The  evaluation,  however,  does  not  indicate  that  EXSYS  does 
not  provide  the  explicit  capability  to  be  integrated  and  embedded  within  conventional  code. 

The  NEXPERT  OBJECT  and  KES  shells  have  been  specifically  designed  to  allow  easy 
integration  into  existing  coni^uting  environments.  NEXPERT  can  commimicate  with  as  well  as 
be  controlled  by  external  programs.  It  can  also  call  user-written  procedures  and  pass  parameters 
to  these  procedures.  Within  NEXPERT,  these  external  procedures  are  called  from  Execute 
statements.  NEXPERT  allows  applications  to  communicate  directly  and  dynamically  during  the 
inference  process  with  relational  databases.  NEXPERT  also  provides  a  run-time  library  in  "C"  to 
enable  NEXPERT  based  applications  to  be  seamlessly  embedded  within  other  system  applications. 
The  shell  is  designed  for  complete  integration  of  AI  applications  into  operational  environments 
based  on  programs  or  processes  written  in  C,  Fortran,  Ada,  Cobol,  Pascal,  assembly  language  rmd 
others. 


The  KES  shell  also  provides  extensive  flexibility  for  integrating  knowledge-based  systems 
with  other  conventionally  developed  software  applications.  KES  offers  three  distinct  methods  of 
integrating  knowledge-based  applications.  The  "Embedded  Interface"  is  the  KES  facility  that 
allows  a  Imowledge-based  application  to  be  run  as  a  module  of  a  controlling  "C"  or  other  source 
program.  KES  provides  up  to  150  functions  that  allow  direct  access  to  internal  KES  data  types 
and  commands.  The  KES  "Externals  facility"  allows  a  knowledge  based  system  to  execute  other 
software  applications  and  to  communicate  with  these  applications  via  text  files.  The  final  method 
is  the  LINK  facility.  The  LINK  is  a  KES  facility  that  integrates  ORACLE  or  other  relational 
databases  with  any  KES  knowledge  base. 

The  COSMIC  CLIPS  shell  also  provides  a  mature  capability  to  be  integrated  and 
embedded  within  other  conventionally  developed  programs.  The  CLIPS  shell  allows  it  to  be 
integrated  with  other  C  programs  as  well  as  software  written  in  other  languages  such  as 
FORTRAN  and  Ada.  QLIPS  includes  a  math  library  which  can  be  accessed  by  other  C  programs 
provides  features  which  allow  it  to  be  manipulated  externally.  The  COSMIC  CLIPS  product  also 
includes  source  code  which  enables  developers  to  incorporate  unique  developed  C  routines  into 
the  shell  software.  An  expert  system  developed  with  COSMIC  CLIPS  can  easily  be  embedded 
within  other  C  programs  and  be  called  as  a  subroutine.  The  manual  provided  with  the  COSMIC 
CLIPS  package  includes  extensive  information  about  embedding  CLIPS  within  other  system  and 
the  advanced  programming  guide  describes  how  CLIPS  can  be  called  fr-om  a  program  written  in 
virtually  any  language  that  can  make  external  language  calls. 

The  design  approach  used  by  the  GURU  expert  system  shell  provides  an  expert  system 
shell  within  a  common  development  environment.  GURU  is  an  integrated  tool  made  up  of  an 
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e]q)ert  syston  shell,  a  relational  database,  a  general  purpose  text  processing  ability,  gothics 
ct^Mdnlities  and  several  other  general  computer  processing  functions.  GURU  provides  a 
reasonably  complete,  self-contained  development  environment  but  does  not  easily  provide  for 
external  bridges  and  cannot  be  easily  embedded  within  other  developed  i^lications.  GURU  can 
interface  with  external  databases  and  spreadsheets  through  Data  Interchange  Format  (DIF)  files. 
The  ability  to  embed  GURU  within  another  conventionally  develc^)ed  system  is  not  a  feature 
provided  with  the  package.  GURU'S  approach  is  to  integrate  seve^  different  applications  into  a 
common  development  environment 

3.2. 1 .4  Vendor  Evaluations 

In  addition  to  evaluating  the  technical  merits  of  expert  system  shells,  criteria  were 
established  to  measure  vendor  technical  support,  vendor  viability  Gong  term  survival),  and  market 
acceptance  (defacto  standards).  The  survey  considered  such  things  as  the  number  of  systems 
sold,  the  number  of  actual  fielded  systems,  and  the  number  of  iiK3?emental  releases  over  the 
product  life.  Incremental  releases  were  used  as  a  gauge  to  determine  the  type  of  support  and 
enhancements  the  shell  might  receive  in  the  future.  The  survey  also  considered  training, 
documentation,  consulting  capabilities  and  the  length  of  time  that  vendor  orgartizations  have  been 
in  business. 

EXSYS,  developed  and  marketed  by  EXSYS,  Inc.,  was  first  released  in  1983.  Since  that 
time  the  shell  has  gone  through  three  majcx'  revisions,  with  the  current  version  3.1  having  been 
released  in  July  1987.  The  EXSYS  corporation  is  located  in  Albuquerque,  New  Mexico  and  has 
provides  free  telephone  technical  support.  Independent  product  reviews  indicate  that  the 
company  has  a  solid  reputation  and  that  EXSYS  is  in  wide  use.  EXSYS,  Inc.'s  user  telephone 
suppon  is  very  thorough  and  their  support  employees  have  a  through  understanding  of  the 
product 

Neuron  Data  Inc.,  the  developer  of  NEXPERT  OBJECT,  is  also  a  small  rapidly  growing 
company.  Neuron  Data  was  incorporated  in  1985  and  released  the  first  version  of  NEXPERT 
OBJECT  in  the  fall  of  that  year.  Since  that  time  the  company  has  released  four  major  revisions  to 
NEXPERT  OBJECT  and  plans  to  release  its  latest  version  (V2.0)  in  the  summer  of  1990.  The 
company  has  indicated  that  they  have  sold  and  distributed  over  7(X)0  systems.  A  distribution 
arrangement  with  Digital  Equipment  Corporation  (DEC)  permits  customers  to  buy  the  tool  and 
obtain  support  from  DEC  and  Bechtel  Information  Systems  (training  support).  Neuron  Data 
provided  numerous  articles  praising  the  capabilities  of  NEXPERT  OBJECTT  and  produced  an 
extensive  list  of  applications  in  use  by  noted  corporations  around  the  world. 

Software  A&E,  the  developers  of  KES,  have  identified  themselves  as  the  "oldest  profitable 
expert  system  shell  developer"  in  the  expert  system  arena.  The  company  introduced  its  first 
expert  systems  building  tool,  KES  I,  in  1983.  The  tool  was  initially  developed  in  LISP,  but  was 
completely  re-engineered  in  "C"  in  1985  to  provide  more  flexible  integratimi  capabilities.  Since 
being  re-engineered,  KES  has  gone  through  seven  major  revisions.  Software  A&E  advertises  that 
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a  new  versi(»  of  KES  is  released  at  least  once  a  year  and  that  each  new  release  is  both  upward 
and  downward  compadble.  KES  is  Software  A^'s  major  software  product  and  thus  receives  a 
corpcHate  emphasis  to  maintain  it  as  a  leading  expert  system  product.  Because  of  the  modular 
structure  of  the  KES  shell.  Software  A&E  is  able  to  add  new  and  improved  functionality  to  the 
shell  very  easily  and  quickly.  The  company  offers  consulting  services  and  builds  expert  systems 
fOT  numerous  customers,  including  government  agencies.  Software  A&E  provides  full  support 
for  KES  licensees  including  telephcme  consultation,  software  updates  and  training  courses  whic 
are  offered  on  a  regular  basis.  Software  A&E's  headquarters  and  training/development  facility  i 
located  within  20  miles  (in  Arlington,  Virginia)  of  I^Cs  development  facility.  ^ 

The  COSMIC  CLIPS  shell  is  a  product  of  the  AI  section  of  the  National  Aeronautics  and 
Space  Administration  (NASA)  at  Johnson  Space  Center  in  Houston,  Texas.  The  original 
development  goal  was  to  build  a  highly  portable,  low-cost  expert  system  tool  that  ccHild  be  easily 
integrated  with  external  systems.  The  result  was  CLIPS  (C  language  Integrated  Production 
System).  CLIPS  is  cuirendy  in  use  at  several  NASA  locations  and  is  distributed  to  the  private 
industry  and  academic  sectors  through  its  nonprofit  unit  Computer  Software  Management  and 
Information  Onter  (CX)SMIC),  located  at  the  University  of  Georgia.  COSMIC  has  served  the 
NASA  agency  for  twenty-five  years  distributing  NASA-developed  software.  Technical  support 
for  COSMIC  CLIPS  is  not  as  complete  as  the  commercial  packages,  but  is  provided  at  no  charge. 
No  information  was  available  on  platmed  enhancements  a*  future  technical  support 

GURU  is  a  product  of  Micro  Data  Base  Systems,  Inc.  (MDBS)  located  in  Lafayette, 
Indiana.  The  company  has  been  in  operation  for  several  years  and  is  best  known  for  its  MDBS  in 
and  KnowledgeMan  programming  packages.  Most  of  MDBS’s  products  are  sold  to  developers 
for  specialized  applications.  GURU  was  first  released  in  January  of  1985  and  since  that  time  has 
undergone  three  major  revisions.  A  reviews  of  GURU  documentation  indicates  that  while 
massive,  it  is  poorly  organized  and  difficult  to  use.  The  documentation  intersperses  information 
on  the  expert  shell  with  instructions  pertaining  to  the  other  components  of  the  integrated  package. 
GURU  manuals  are  primarily  oriented  toward  persons  already  familiar  with  MDBS's  other 
products.  The  company  does  offer  three-day  workshops  which  focus  on  the  expert  system 
component  of  the  package. 

3.2.2  Conclusions 

Based  on  specified  and  derived  KB  MLS  requirements  and  on  the  preliminary  architecture 
of  the  demonstration  system,  the  original  population  of  twenty-five  expert  system  tools  was 
reduced  to  eight  Two  major  criteria  used  to  produce  this  population  reduction  were:  selection  of 
UNIX  as  the  KBMLSI  operating  and;  the  contractually  specified  requirement  to  build  the 
demonstration  system  with  a  minimal  amount  of  new  software  development  Of  the  eight 
remaining  expert  system  shells,  three  (OPS-20(X),  ESP  ADVISOR,  and  CbcPERT)  were  eliminated 
based  on  the  absence  of  sufficient  documentation  or  other  literature  which  could  substantiate  their 
technical  features.  From  the  information  available,  an  assessment  was  made  that  these  four 
systems  would  not  provide  the  necessary  functionality  required  for  development  of  the  KBMLS 
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prototype. 


Table  3.2.1-2  summarizes  the  ratings  given  to  each  of  the  five  shells  ^iriiich  were 
evaluated  The  ratings  are  reflective  ttf  the  varied  capabilities  and  features  of  each  shell  An 
overall  score  was  calculated  f(M*each  shell  and  was  used  in  die  final  leaMnmendatioo  and 
selection.  Scoring  is  based  on  a  scale  from  zero  to  ten  with  ten  representing  full  sadsfactkm  of 
criteria  requirements. 

In  evaluating  the  power  and  flexibility  of  knowledge  representation  and  inferencing,  both 
KES  and  NEXPERT  received  the  highest  scores.  Both  possess  powerful  knowledge 
representation  mechanisms  and  both  provide  multiple  ways  of  inferencing  with  knowledge.  Based 
on  the  complexities  of  the  sanitization  problem,  evaluaticxi  criteria  established  power  and 
flexibility  of  representing  and  inferencing  with  knowledge  as  critical  factors  in  the  development  of 
the  demonstration  system. 

The  ability  of  a  shell  to  be  embedded  within  other  conventionally  developed  software  was 
also  a  critical  evaluation  criteria.  The  KBMLS  prototype  architecture  is  predicated  chi  the  ability 
of  the  expert  system  to  be  embedded  within  conventionally  developed  software.  The  ability  of  the 
shell  to  provide  conventional  programming  language  interfaces  was  determined  to  be  essential  in 
building  a  seamless,  integrated  system.  Tluee  of  the  five  shells  evaluated  were  q)ecifically 
designed  with  this  capability.  K£S,  NEXPERT  and  CLIPS  all  possess  the  characteristic  of  easy 
integration  into  existing  computing  environments.  All  tiiree  provide  the  necessary  features  for 
successful  development  and  demonstration  of  the  KBMLS  prototype.  The  EXSYS  and  GURU 
expen  systems  do  not  specifically  provide  these  capabilities  and,  as  a  result,  received  lower 
scores.  While  EXSYS  and  GURU  do  provide  facilities  for  "bridges"  to  external  programs  and 
data,  they  do  not  provide  the  means  to  completely  and  seamlessly  integrate  an  AI  applicatitxi  with 
conventionally  developed  software. 

In  evaluating  portability/compatibility  two  of  the  shells  were  found  to  have  a  clear 
advantage.  KES  and  NEXPERT  OBJECT  specifically  emphasize  their  portability  and 
compatibility  features.  The  modular  structure  of  KES  is  particularly  appealing  to  the  KBMLS 
development  strategy  for  migration  to  other  hardware  suites  and  q)erating  systems.  The  KES 
design  indicates  that  the  company  is  positioned  to  provide  fiequent  upgrades  to  their  expert 
system,  and  is  consistent  with  their  commitment  to  release  a  major  revision  of  KES  at  least  once  a 
year.  Based  on  these  criteria  KES  received  the  highest  rating  in  this  category. 

The  final  criteria,  vendor  evaluations,  was  used  to  rate  the  quality,  reputation,  long  term 
stability  and  technical  support  of  the  product  The  KBMLS  development  requires  a  shell  that  will 
not  be  discontinued,  scrapped  or  no  longer  supponed  in  the  near  future.  This  criteria  was  also 
used  as  a  gauge  to  possible  future  enhancements  to  the  existing  shell  The  number  of  product 
updates  provides  an  indication  of  that  companies  commitment  to  continuously  inqirove  their 
product  and  to  stay  on  the  leading  edge  of  expert  system  technology.  All  five  shell  developers 
were  evaluated  as  having  quality  products  and  solid  business  reputations  (i.e.  none  were 
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identified  as  "high  risk"  coiporations). 
3.2.3  Recommendations 


KES  and  NEXPERT  received  the  highest  overall  total  scores.  The  final  recommendation 
and  selection  was  ultimately  a  choice  between  these  two  shells.  The  survey  results  indicate  that 
both  shells  possess  the  necessary  capabilities  for  successful  develtpment  and  implementation  of 
the  KBMLS  sanitization  prototype. 

Based  on  a  weighted  analysis,  ESC  recommends  KES  as  the  expert  system  shell  for 
development  and  implementation  of  the  KBMLS  prototype.  KES  was  selected  over  NEXPERT 
on  the  basis  of  four  major  items: 

(1)  Modular  structure.  One  of  the  major  benefits  of  KES  is  the  isolation  of  the  hardware 
and  operating  dependencies  into  a  single,  easily  interchangeable  module.  As  a  result, 
KES  runs  on  more  hardware  platforms  than  any  other  shell  available  on  the  market 
The  modular  structure  also  allows  new  functionality  to  be  added  very  easily. 

(2)  Embedded  interface.  KES  allows  the  expert  system  to  be  easily  embedded  into  other 
applications  and  programs  operating  as  integrated  modules  under  the  control  of  a  "C 
or  other  source  program.  KES  offers  extensive  functions  (over  150  functions)  that 
allow  direct  access  to  internal  KES  data  types  and  commands. 

(3)  Power  and  flexibility.  KES's  power  and  flexibility  ofknowledge  representation  and 
inferencing  were  felt  to  be  slightly  superior  to  NEXPERT  OBJECTS.  Because  of  the 
uniqueness  and  complexity  of  the  automated  sanitization  process  the  more  power  and 
flexibility  in  knowledge  representation  and  inferencing,  the  lower  the  software 
development  risk.  The  KES  shell  offers  the  advantages  of  having  backward  and 
forward  chaining,  and  also  provides  three  types  of  inference  engines. 

(4)  Vendor  proximity.  Software  A&E's  headquaners  and  training  facilities  location  was 
the  contributed  to  the  selection  of  KES.  Because  of  the  inherent  complexity  of 
generating  the  expert  sanitization  rules  and  in  integrating  the  expert  shell  with  KBMLS 
applications  software,  vendor  proximity  and  support  were  established  as  risk  reducing 
evaluation  criteria.  FSC  developers  should  be  able  to  receive  better  technical  support 
with  Software  A&E  being  located  less  than  20  miles  from  FSCs  development 
facilities. 

3.3  Document  Parsing  Tools  Survey 

The  following  subsections  summarize  the  evaluations,  draw  conclusions,  and  present  a 
recommendation. 
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3.3.1  Evaluatkms 


The  KBMLS  prototype  requires  the  capability  to  scan  narrative  text  messages,  parse 
message  elements,  and  store  and  disseminate  information  from  the  narrative  relating  to  the 
questions:  WHO,  WHAT,  WHERE,  WHY,  WHEN  and  HOW  MANY.  A  majcn’ concern  of  the 
evaluators  was  the  tool's  ability  to  understand  and  parse  large  lists  of  specific  wends,  symbols  and 
phrases  as  well  as  its  t^ility  to  handle  the  syntactic  and  semantic  variations  of  reported  items  of 
interest. 

The  survey  identified  a  number  of  parsing  tools  which  provide  a  subset  of  the  allocated 
system  requirements.  The  evaluation  criteria  of  die  tools  were: 

•  The  ability  of  the  COTS  document  parsing  tools  to  perform  keyword^hrase  extraction 

•  Vocabulary  size 

•  Syntactic  and  semantic  coverage  capabilities 

•  The  ability  of  the  COTS  tool  to  be  embedded  within  the  system  and  provide  a  seamless 
integration  between  the  document  parsing  tool  and  the  other  naodules  oi  the  system 

•  Corxqiatibility  with  the  hardware,  operating  system  and  surrounding  application  software 

•  The  ease  of  use,  supplied  interfaces  and  available  documentation. 

The  majority  of  the  tools  evaluated  fell  into  two  broad  categories,  natural  language 
programs  and  textAnfotmation  retrieval  tools.  One  additional  specialty  tool  was  also  identified 
and  evaluated.  The  developers  of  this  tool  categenize  it  as  a  natural  language  "shell";  or  as  a 
hybrid  of  the  other  two  categories. 

3.3. 1 . 1  Natural  Language  Programs 

The  natural  language  programs  were  the  mcne  readily  available  tools  reviewed.  Most  of 
the  natural  language  programs  reviewed  were  tools  which  are  used  to  develop  "friendlier" 
interfaces  to  databases  and  other  software  applicaticms  (See  appendix  B).  For  example,  the  BBN 
Parlance  Natural  Language  Interface,  developed  and  marketed  by  BBN  Systems  and 
Technologies  Inc.,  allovr^  users  to  obtain  information  from  various  relatitmal  databases  by  singly 
typing  in  questions  in  every  day  English.  The  software  parses  a  data  input  string,  interprets  the 
parsed  data,  and  translates  it  into  SQL  statements.  These  natural  language  programs  supply  the 
necessary  linguistic  and  syntactic  capabilities  and  allow  application  software  developers  to  add 
words  and  terms  to  the  tool  dictionary.  The  dictionary  contains  all  those  words  and  phrases 
related  to  the  developers  specific  application,  making  it  domain-specific. 
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Most  of  these  tools  allow  modifications  to  accommodate  other  types  of  applicafions  in 
addition  to  fiont-end  interfaces,  but  the  majority  are  q)6cifically  designed  for  just  diis  one 
purpose.  Manipulating  and/or  modifying  of  these  {nograms  fix’  use  in  other  applications,  such  as 
the  KBMLS  system,  is  difficult  to  accomplish.  The  inability  to  embed  these  nauiral  language 
programs  represents  the  greatest  roadblock.  These  tools,  as  previously  described,  have  been 
specifically  designed  for  end  users  and  do  not  provide  features  for  integratkxi  with  other 
applications.  Independent  reviews  and  other  available  literature  do  not  indicate  that  any  of  the 
natural  language  packages  would  be  able  to  accomplish  the  task  required  by  the  design. 

3.3. 1 .2  Text/Information  Retrieval  Tools 

The  other  set  of  document  parsing  tools  surveyed  were  categorized  as  text/information 
retrieval  tools.  These  tools  have  bwn  specifically  developed  to  manage  and  manipulate  large 
amounts  of  unstructured  narrative  text.  Most  users  of  these  tools  are  concerned  with  rapidly 
locating  word/word  phrases  and  concepts  contained  in  large  volumes  of  narrative.  While  that 
application  does  not  match  a  specific  KBMLS  requirement,  the  tool's  ability  to  identity  and  parse 
word/word  phrases  and  concepts,  provides  the  possibility  of  using  these  tools  document  parsers. 
The  three  tools  evaluated  in  this  category  were  Elexir,  Golden  Retriever  and  Fulcrum's 
Text/Search  (See  appendix  B). 

Like  the  natural  language  programs,  these  tools  are  single  purpose,  text/document 
retrieval  systems.  None  of  the  tools  in  this  category  demonstrate  the  ability  to  perform  syntactic 
or  semantic  operations  nor  are  they  easily  embedded  within  other  applications.  The  tools  are  not 
flexible  or  versatile  enough  to  address  many  of  the  requirements  specified  by  the  KBMLS  design. 
While  both  categories  of  parsing  tools  possess  a  varied  degree  of  capability  to  perform 
keyword/phrase  extraction,  none  are  able  to  be  integrated  with  the  KBMLS  prototype. 

3.3. 1.3  NL  Builder 

Of  the  potential  document  parsing  tools  reviewed,  one  displayed  the  capabilities  of  the 
natural  language  programs  and  text  retrieval  tools,  plus  the  flexibility  to  modify  its  inherent 
functions.  NL  Builder  (Sychronetics,  Inc.)  is  unlike  the  other  natural  language  packages  in  that  it 
allows  the  developer  to  define  a  specific  natural  language  process  without  programming.  In  other 
words,  a  developer  can  build  a  domain  specific  natural  language  program.  This  task  is  reduced  to 
that  of  building  a  lexical  database  to  describe  the  target  language  or  sub-language  ("jargon").  NL 
Builder  provides  capabilities  for  syntactic  and  semantic  analysis  of  sentences.  Syntax  and 
semantics  are  interleaved  at  a  granularity  of  the  developer's  choice.  The  developer  is  required  to 
build  the  lexical  database  consisting  of  words,  word  senses,  features  on  word  senses,  syntactic 
grammar  and  semantic  representation  and  the  tool  completes  the  process.  Sychronetics 
emphasizes  that  NL  Builder  is  a  Natural  Language  shell,  not  a  natural  language  program.  It  is 
written  entirely  in  the  C  language  and  provides  an  extensive  C  language  interface  allowing  for 
easy  integration  and  manipulation  in  the  application  software  environments. 
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3.3.2  Conclusioiis 


After  identifying  and  evaluating  the  two  generic  types  cf  to(^  Natural  Language  and 
Text/Document  Retrieval  tools,  an  evaluation  the  tool  peculation  determined  that  die  sanc^^ 
commercially  available  tools  ftv  document  parsing  do  not  meet  the  required  specifications  of  the 
KBMLS  prototype.  One  tool  that  did  represent  potential  for  integration  with  the  KBMLS 
prototype  is  NL  Builder. 

NL  Builder  is  advertised  as  a  Natural  Language  Shell  versus  a  natural  language  program. 
Its  primary  advantage  over  die  other  surveyed  mols  is  that  it  is  not  specifically  designed  as  an  end 
user  product  NL  Builder  has  the  capability  to  be  integrated  and  embedded  into  other  iqiplicatitxis 
and  is  flexible  enough  to  allow  the  an  application  software  developer  to  adjust  the  toed  to  handle 
specific  application. 

3.3.3  Recommendations 

Based  on  the  absence  of  other  tools  which  could  provide  the  necessary  KBMLS 
functionality,  NL  Builder  is  identified  as  the  only  parser  possessing  a  sufficient  number  of  the 
required  features  needed  in  the  development  of  the  KBMLS  prototype. 

4.  KBMLS  SANITIZATION  PROTOTYPE  DESIGN 

4.1  General 

Implementation  of  the  Sanitization  Model  resulted  in  the  development  of  a  single 
Computer  Software  Configuration  Item  (CSQ)  known  as  the  Knowledge  Based  Multi-level 
Secure  (KBMLS)  Sanitization  Prototype.  The  following  subsections  presents  the  design. 

4.2.  KBMLS  CSQ  Overview 

The  Knowledge  based  Multi-level  Secure  (KBMLS)  (}SQ  supports  the  mission  of 
USAFE  by  providing  an  accredited  interface  for  direct  electrical  exchange  of  information  between 
USAFE's  TS/SQ  level  (or  "high")  intelligence  production  centers  and  a  SECRET  level  (or  "low") 
network.  This  network  is  the  Intra-Theater  Intelligence  (Communications  Network 
(IINCOMNET).  Given  tasking  from  the  operatcH’,  the  KBMLS  (CSQ  either  automatically  or 
interactively  identifies  intelligence  data  of  interest  to  tactical  wing  ctxnmanders  and  extracts  the 
data  from  the  "high"  side,  sanitizes  the  data,  and  distributes  the  data  to  the  "low"  side. 

KBMLS  is  capable  of  providing  automatic  identification,  sanitization,  and  product 
generation.  In  addition,  KBMLS  is  capable  of  automatically  categorizing  sensitive  information 
into  one  of  the  following  categories  for  operator  review. 

•  Immediately  Releasable  (requires  no  sanitization) 


•  Samtued  Releasable  (has  been  sanitized) 

•  Conditionally  Releasable  (sanitizatkm  is  authorized  only  if  condititMis  are  met) 

•  Not  Sanitizable  (sanitization  not  autiKxized) 

KBMLS  is  designed  to  run  on  a  UNIX  System  V  Operating  System,  with  OSF/MOTIF  X- 
Windows,  hosted  cm  a  DATAWATCH  386  Wcxkstation.  The  target  external  cemaponents  of  th 
KBMLS  Coiiq)uter  Architecture  are  shown  in  Figure  4.2  and  identified  as; 

•  USAFE IDHS  -  United  States  Air  Force  in  Europe  (USAFE)  Intelligence  Data  Handli 
System  (IDHS) 

•  KBMLS  -  Knowledge  Based  Multi-level  Secure  Sanitization  Prototype 


•  USAFE  GUARD  -  SC3  to  NATO  Gateway  system. 


Figure  4.2  KBMLS  Prototype  within  USAFE  Computer  Architecture 


The  KBMLS  supports  the  mission  of  the  KBMLS  Architecture  by  performing  high 
interest  activity  screening,  associating  new  information  to  existing  infoimation,  sanitization  of 
critical  intelligence  infexmation,  and  disseminatiem  of  sanitized  intelligence  infoimation  either 
automatically  or  at  an  operatcir's  discretion. 

The  purpose  of  the  interface  to  the  USAFE  IDHS  is  to  receive  message  traffic  (fen: 
example  TACREPS,  TACELINTS,  IIRs);  query  and  receive  related  messages  from  message 
queues;  query  and  receive  up  to  date  information  on  routes  and  schedules  of  reconnaissance 
aircraft;  query  and  receive  (^rder  of  Battle  (OB)  data  Base  records  for  Air  and  Missile;  and  send 
OB  update  records  back  to  the  USAFE  IDHS  whenever  update  criteria  has  been  met 
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The  piupose  oi  the  interface  to  the  US AFE  GUARD  is  to  disseminate  sanitized 
intelligence  infonnation  to  wing  commanders.  The  GUARD  performs  a  redundancy  check  on  the 
classification  and  data  to  rasure  the  intelligence  informatk»  can  be  disseminated  to  wing 
commanders. 

4.3  KBMLS  CSCI  Architecture 

The  internal  organizational  structure  of  the  KBMLS  protMype  is  depicted  in  FIGURE  4.3. 
As  shown,  the  KBMLS  is  composed  oi  four  Computer  Software  CcMiqxMients  (CSC): 

•  Data  Translation  Component  -  Translates  sensitive  information  into  Sanitization  Case 
Folders 

•  Sanitization  Component  -  Determines  need,  sensitivity,  cover,  and  mediod  of 
sanitization,  then  generates  sanitized  infcHrmatioiL 

•  Executive  Control  Coiqponent  -  lYovides  system  control  and  system  security. 

•  Global  Utilities  Component  -  Provides  interface  routines  to  system  services,  external 
i/o,  data  base,  and  display  i/o. 


Figure  4.3  KBMLS  Prototype  Diagram 


The  purpose  of  the  Data  Translation  (Component  is  to  perform  automatic  receipt,  parsing, 
and  storage  of  TACREP  and  TACIELINT.  Then  route  sensitive  infemnation  (of  high  interest  to 
tactical  wing  commanders)  for  further  processing  to  the  Sanitization  Component  to  establish  links 
to  existing  intelligence  information  which  will  be  used  in  the  sanitization  process.  In  addition,  it 
provides  for  the  maintenance  and  tailoring  of  data  translation  rules.  To  identify  and  understand 
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incoming  messa^  a  parsing  technique  called  Translad<»  Gnumnars  was  selected  to  contrd  the 
parsing  and  translation  (rf  incoming  messages  into  an  internal  data  structure.  The  Translation 
Grammar  Technology  was  furnished  by  the  Army  duough  FSCs  involvement  with  st^tware 
develc^nnent  for  the  Commra  AIXXS  Suppm  Software. 

The  Sanitization  Ccnziponent  determines  whether  the  sensitive  informatkm  can  be  sanitized 
and  if  so,  performs  sanitizatioa  of  sensitive  informadon  for  potential  dissemination  u>  wing 
(xmunanckrs.  The  deciskm  making  is  inq)lemented  u^g  Artificial  Intelligoice  techniques.  The 
Knowledge  Base  Expert  Systems  (KES)  Grmmercial  Off  The  Shelf  (COTS)  software  is  used  to 
control  the  sanitization  process.  The  sanitization  comptMiem  provides  a  set  (tf  functions  to  allow 
analysts  to  review,  generate,  update,  and  disseminate  sanitized  intelligence  informatitm  or  perform 
those  function  automatically.  In  addition,  it  provides  ftv  the  maintenance  and  tailtving  of 
sanitization  tables  and  knowledge  base. 

The  Executive  Control  Component  performs  system  sovices  and  provide  a  multi-level 
secure  environment  It  controls  and  monitors  system  resources  and  provides  maintenance  and 
tailoring  of  system  and  security  data. 

The  Global  Utilities  Coirponent  is  a  set  of  libraries  which  contain  software  conunon  to  all 
other  components.  It  performs;  intemal/extemal  communications,  system  services,  and  common 
display  services.  System  services  to  manage  of  file  and  files  with  data  structures  is  inoplonented 
through  calls  to  C  B  TREE  an  A  B-tree  file  managen^nt  system.  To  keep  inline  with  current 
trends  and  standards  in  human-computer  interaction,  XSIGHT  an  OSF/MOTIF  X-Window  Run¬ 
time  system,  was  employed  so  the  results  of  KBMLS  automated  sanitization  can  be  reviewed  and 
modified  by  authorize  site  personnel 

4.3. 1  KBMLS  Internal  Interface  Data  Structures 

KBMLS  internal  interface  common  data  structures  are  stated  below; 

•  Sanitiyatinn  Case  Folders  is  a  complex  record  structure  which  contains  a  complete 
audit  trail  of  events,  decisions,  and  manipulations  that  occurred  during  the  sanitization 
process. 

•  System  History  log  packets  and  Security  Audit  Trail  log  packets  are  log  entries  and 
passes  by  mothiles  to  logging  software.  Each  entry  is  and  80  character  string  with 
indicates  either  a  system  level  event  or  a  security  relevant  event 

•  Message  Log  packet  is  a  collection  of  the  messages  and  summary  record  which  is 
passed  by  modules  to  logging  software  for  storage  in  KBMLS  logs. 

•  System  control  messages  are  used  to  pass  low  level  commands  to  software  for  startup 
and  shutdown. 
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4.3.2  KBMLS  System  States  and  Modes 


The  KBMLS  system  has  two  system  states  and  within  the  interactive  state  has  three 
modes  of  (iterations,  as  defined  from  and  end  usos  poant-of-view.  The  system  states  and  modes 
are  defined  as  frdlows: 

•  Automatic  Mcxie  is  when  the  system  runs  auttxnatically  (without  c(»tinuous  mcmitodng 
by  users)  parsing  messages,  researching,  and  sanitizing  incoming  message  traffic  for  later 
review  by  analysts. 

•  Interactive  Mode  is  when  some  user  (Analyst,  System  Manager,  or  Security  Manager)  is 
logged  in.  While  in  the  interactive  mode  die  system  can  be  in  one  of  three  states;  Analyst, 
System  Manager,  or  Security  Manager. 

•  In  the  Analyst  state  the  following  activities  can  be  perfrnmed:  review  case  folders; 
release  sanitized  messages;  update  the  Oider-of-Battle  Data  base;  resubmit  case 
folders  frv  reprcxtessing;  and  reviewAelease  daily  and  monthly  products. 

•  In  the  System  Manager  state  the  following  activities  can  (tecur:  startup  and  shutdown 
of  the  system;  monitoring  execution  of  the  software,  logging,  and  disk  usage;  and 
perform  maintenance  tasks  on  the  case  folder  data  base,  knowledge  base,  criteria  files, 
and  logs. 

•  In  the  Security  Manager  state  the  following  activities  can  occur  update  user  access 
table;  and  review  and  archive  the  security  audit  trail  log. 

Only  one  state  can  be  active  at  one  time  and  both  the  automatic  mode  and  interactive 
mode  maybe  active  at  the  same  time. 

4.4  M(xlule  Descriptions 

The  coniponents  of  the  KBMLS  prototype  represent  a  collection  of  mcxlules  and  routine 
libraries.  Each  component,  with  its  associated  modules  and/or  libraries  is  presented  in  Figure  4.4. 
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Hgure4.4  KBMLS  Hierarchy  Diagram 


4.4. 1  Data  Translation  Oxnponent  Module  Descriptims 

The  Data  Translation  component  provides  die  functionality  to  parse  and  process  incoming 
information.  The  component  is  cooqnised  of  four  modules:  the  Gramnoar  Maintenance  Display  to 
modify  parsing  grammars,  the  Grammar  Gimpiler  to  generate  niles  sets,  the  Data  Translator  to 
serve  as  the  automatic  driver  for  processing  messages,  and  the  Grammar  Executive  to  parse 
incoming  messages.  Figure  4.4. 1  depicts  the  interfaces. 

4.4. 1 . 1  Data  Translate  Module 

The  Data  Translator  (DT)  contains  the  functionality  to  receive  messages  hrom  an  external 
source,  perfoin  all  the  automated  parsing  of  incoming  messages  and  forwarding  of  sanitization 
case  folders  to  the  pre-sanitizer.  In  doing  so,  the  DT  module  invokes  the  Grammar  Executive  to 
parse  the  messages.  The  DT  module  performs  the  following  functions: 

(1)  Generation  of  sanitization  case  folders  based  on  messages  for  which  parsing  rules  are 
available. 

(2)  Creation  and  updating  of  disk-resident  databases  based  upon  analyst  interacticxi. 

(3)  Duplicate  message  processing. 

(4)  Assign  new  security  classirications  to  each  sanitization  case  folder  based  upon  message 
classificaticm. 
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Figure  4A1  Data  Translator  Component  Module  Diagram 


The  DT  process  loads  all  of  the  parsing  data  used  by  the  automatic  parser  into  memory. 
This  data  includes  applicable  subsets  of  the  Parsing  Definition  Tables.  During  normal  operation, 
no  disk  accesses  are  performed  the  DT  software,  thereby  maximizing  message  processing 
throughput  After  a  message  has  been  received,  it  is  parsed  via  the  Grammar  Executive  with  the 
Message  Header  Rules  to  determine  whether  the  message  is  a  TACREP  ot  a  TACELINT. 
Message  header  information  is  extracted  frnn  the  message  and  is  stored  in  die  sanitization  folder 
and  the  message  abstract  After  the  message  header  parsing,  the  message  is  checked  to  ensure 
that  the  message  is  not  a  duplicate  of  a  previously  received  message.  Each  time  the  DT  is  started, 
certain  information  for  the  most  recent  1200  messages  received  while  the  process  has  been  active 
is  stored  in  memory  for  as  long  as  the  process  is  active.  If  the  message  matches  a  previous 
message,  it  is  not  forwarded  to  the  sanitizer.  After  the  message  type  has  been  determined,  the 
rules  pertaining  to  the  individual  message  type  are  utilized  to  parse  the  message.  The  Grammar 
Executive  extracts  information  from  the  message  and  stores  it  in  the  sanitization  case  folder. 
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4.4. 1 .2  Grammar  Executive  Module 


The  Grammar  Executive  consists  of  a  general  parsing  utility  to  extract  infonnation  firom  a 
message  based  upon  rules  defined  for  the  format  of  the  message.  The  parsing  tables  are  generated 
by  the  Granomar  Compiler.  The  grammar  executive  is  a  utility  procedure  invt^ed  by  die  Data 
Translator  to  parse  information.  The  Grammar  Executive  utilizes  parsing  rules  containing 
message  fcamat  rules  to  parse  incoming  messages.  Grammar  rules  are  used  for  input  message 
processing,  and  combine  the  lexical  analysis  and  syntactic  analysis  tasks  for  parsing  messages. 
Based  on  the  grammar  rules,  the  Grammar  Executive  extracts  and  foitnats  the  infcnmation  that  is 
to  be  put  into  a  sanitization  folder. 

4.4. 1 .3  Grammar  Compiler  Module 

The  Grammar  Compiler  process  generates  rules  for  the  Grammar  Executive  to  use  fnxn 
english  language  rules  created  by  the  analyst  via  the  user  interface.  Two  types  of  tables  comixise 
the  databases:  Parsing  Rules  and  Reference  tables.  These  tables  are  used  to  extract  information 
from  incoming  messages  during  automatic  parsing.  The  Grammar  Maintenance  Display  creates 
and  edits  parsing  rules.  The  Grammar  Compiler  process  transforms  parsing  rules  into  the  f(»mat 
necessary  for  use  by  the  Grammar  Executive.  The  User  Interface  process  provides  the  capabilities 
to  edit,  delete,  print  or  create  rules  used  in  parsing  incoming  information.  These  rule  sets  include: 
header  parse  rules,  message  format  rules,  data  set  rules,  field  level  rtiles  and  common  rules.  This 
module  performs  the  processing  required  to  transform  p-meta  rule  statements  into  parsing  tables 
in  meta  object  format  These  tables  are  used  by  the  grammar  executive  to  perform  the  parsing 
and  validation  of  informatiott 

4.4. 1 .4  Grammar  Maintenance  Display  Module 

The  Grammar  Maintenance  Display  allows  the  user  to  manipulate  the  KBMLS  input 
message  parsing  grammars.  The  user  can  add,  edit  delete,  compile,  enable,  and  review 
grammars,  and  testae  grammar  file  directory  baselines.  The  compiled  grammar  objects  are  used 
by  the  data  translator  to  parse  the  incoming  message  traffic  and  are  oi-line  modiHable  to  allow 
making  changes  to  support  new  message  formats  without  requiring  a  rebuild  of  the  KBMLS 
software.  The  Grammar  Association  Table  (GAT)  maintains  the  grammar  name,  the  grammar 
dependencies,  and  the  type  of  grammar. 

4.4.2  Sanitization  Component  Module  Descriptions 

The  Sanitization  Component  provides  the  functionality  to  sanitize  sensitive  information 
and  format  the  sanitized  information  into  an  outgoing  product  after  passing  a  set  of  rule  based 
authorization  logic  which  either  authorizes  or  denies  sanitization.  'Die  component  is  comprised  of 
six  modules  and  one  routine  library  fa  access  to  the  scf  data  base.  The  six  modules  are  the  Pre- 
Sanitizer,  the  Sanitizer,  the  SCF  Review  Display,  the  Review/Release  Display,  the  Knowledge 
Base  Maintenance  Display,  and  the  Sanitization  File  Maintenance  Display.  Figtire  4.4.2  depicts 
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the  modules  and  the  interfaces  among  them. 
4.4.2. 1  Pre-Sanitizer  Module 


The  Pre-Sanitizer  determines  i/and  how  the  message  will  be  sanitized.  The  Pre-Sanitizer 
retrieves  the  SCF  from  the  Data  Base  and  searches  to  establish  links  to  existing  "LIKE"  SCFs.  V 
null  linking  results  in  a  New  Unit  and  continues  processing.  A  duplicate  check  determines  if  tht 
information  in  the  SCF  is  New  or  duplicate.  The  Pre-Sanitizer  ctxitains  an  In_Area  Algwithm 
Area  tests  are  provided  for  circles,  rectangles  and  polygons. 


■  Sanitized 


Figure  4.4.2  Sanitization  Component  Module  Diagram 

The  Pre-Sanitizer  interacts  with  the  expert  system  by  executing  a  script  which  backward 
chains  through  four  sets  of  sanitization  rules.  KES  is  the  Knowledge  Based-Expert  System  shell. 
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Those  rule  sets  are: 


•  ^ficdLEuks  specify  who  has  interest  as  it  relates  to  the  need  to  know.  Rules  are 
ccMistructed  based  on  When  (tinie).  Where  Gocation),  What  (activity),  and  Who  (unit) 
Infonnation.  These  rules  yield  a  list  of  addressees. 

•  Sensitivitv  Rules  pertain  to  message  type,  classification  and  classification  markings, 
source,  method,  and  special  conditions  such  as;  confirmation  needed  or  agreements  with 
host  nation.  These  rules  can  prevent  information  frcHn  being  sanitized. 

•  Coverage  Rules  are  divided  into  Allowable  Source  Rules  and  Preferred  (2over  Rules, 
which  surround  the  PlausiUe  Cover  Algcnithm.  Within  the  IMausible  Cover  Algoiidim  a 
Source  Equivalency  Match  function  searches  the  Coverage  Table  for  units  which  have 
similar  sources  and  creates  the  Candidate  Coverage  List  An  Area/  Time  Match  FuncdtHi 
attempts  to  determine  fiom  the  Candidate  Coverage  List  what  candidates  were  in  die  area 
at  the  Time  of  Intercept  The  candidates  which  were  in  area  at  the  right  time  are  entered 
into  a  Suitable  Coverage  List  A  Status  of  Forces  (^eck  Function  accesses  status 
information  in  the  Coverage  Table  to  determine  which  units  qualify  as  either  Plausible 
Cover  or  Reasonable  Source.  Attributes  from  the  Sanitization  Case  Folder  are  used  with 
the  Preferred  Cover  Rules  to  select  the  Preferred  Cover. 

•  Method  Rules  are  used  to  determine  the  extent  and  fiarmat  of  sanirizarion.  Such  as; 
accuracy,  deletion  and  replacement  criteria,  and  the  Format  of  Sanitized  Information. 
These  Rules  are  driven  by  attributes  populated  by  the  Need,  Sensitivity,  and  Coverage 
Rules. 

The  Hold  Test  examines  each  "LIKE"  SCF  to  determine  if  the  new  SCF  satisfies  any  Hold 
Conditions  such  as;  Needs  Less  Sensitive  Source  or  Needs  Confirmation. 

4.4.2.2  Sanitizer  Module 

The  Sanitizer  Module  performs  the  sanitization  and  reformatting  of  sensitive  information. 
It  receives  instructions  from  the  Pre-Sanitizer  module  which  govern  the  sanitization  of  sensitive 
information.  The  Sanitizer  builds  an  instruction  set  using  Sanitization  Tables.  The  first  pass  uses 
the  instructions  to  create  the  execute  instructions.  The  second  pass  makes  the  deletions  and 
replacements  using  the  execute  instructions.  The  following  search  algorithms  are  used; 

•  Search  /  Fill  firom  Case  Folder  -  Replace  keywords  in  message  template  with  information 
from  a  specific  Case  Folder 

•  Search  /  Delete  -  Search  for  a  word  or  phrase  and  delete  the  word  or  phrase,  sentence,  or 
paragraph  where  it  was  found 
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•  Search  /  Round  •  Search  for  a  real  number  and  round  to  any  given  precision 

•  Search  /  Replace  -  Search  for  a  word  <x  phrase  and  replace  the  word  ex’  phrase,  sentence. 

(X  paragrq)h  where  it  was  found  with  aruother  specified  word  or  phrase. 

Search  ciq)abilities  include;  Wildcard  Searching,  Case  Sensitive  Searches.  Generalized  Spell 
Checking,  Recognizing  Transposed  Characters,  and  Simple  Typo  Recognition. 

The  Sanitizer  module  updates  the  Case  Folder  with  the  sanitized  message  which  is 
then  written  to  die  Sanitization  Case  Folder  database. 

4.4.2.3  SCF  Review  Display  Module 

The  SCF  Review  Display  Module  is  called  by  the  Analyst  Display  Module  when  die 
analyst  selects  one  of  four  types  of  SCF  reviews  from  the  SCF  Review  option.  The  options  are; 
releasable  SCFs,  sanitized  SCTs,  conditional  SCFs  and  browse  SCFs  by  unit  name.  During  SCF 
Review,  the  analyst  has  the  following  available  options: 

•  Releasable,  an  additional  window  allows  the  user  to  review  SCF  messages  for  each 
specific  category  or  by  unit  name. 

•  Summary,  a  window  will  appear  cemtaining  the  various  fields  from  the  case  folder  for 
the  analyst  to  review. 

•  Justify,  the  window  shows  the  justification  for  the  sanitization  that  has  taken  place  for 
this  message. 

•  Related,  a  window  will  be  displayed  showing  aU  the  case  folders  which  have  the  same 
unit  name  as  the  currendy  displayed  case  folder. 

•  RFLHA.SF.  the  Review/Release  Display  Module  is  activated  and  displays  the  Release 
window. 

•  Resubmits  SCF.  the  case  folder  will  be  resubmitted  to  the  KES  knowledge  base  and 
any  appropriate  sanitization  will  be  done. 

•  Resubmit  MSG,  the  message  will  be  resubmitted  to  the  data  translator  to  be  reparsed. 

•  Store  SCF.  the  SCF  will  be  put  into  the  stored  category  and  will  no  longer  appear  in 
the  releasable,  sanitized,  or  conditional  list.  It  still  can  be  accessed  as  a  related  unit  or 
through  the  browse  option  which  is  described  in  a  later  section. 
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4.4.2.4  Review/Release  Diqilay  Module 

The  Review/Release  Di^lay  Module  is  activated  when  die  user  elides  the  RELEASE 
option  finxn  the  analyst  display.  The  analyst  may  either  sdect  to  srad  the  sanitized  message  Rv 
ouqiut  (to  USAFE  GUARD)  or  to  caned  and  return  to  the  previous  level  menu. 

4.4.2.5  Knowledge  Base  Maintenance  Display  Module 

The  KB  Maintenance  Displays  allows  the  system  administrator  to  review,  add,  modify, 
and  delete  knowledge  based  rule  set  files.  The  knowledge  files  are  used  by  the  Pre-Sanitizer's 
KES  CGTS  software  to  execute  the  knowledge  based  rules  during  processing.  This  di^lay 
allows  the  system  administrator  to  change  the  rules  that  govern  the  criteria  for  sanitization.  The 
system  administrator  also  activates  die  desired  rule  set  file  for  automated  sanitizatiem  processing. 

4.4.2.6  Sanitization  Hie  Maintenance  Display  Module 

The  Sanitization  File  Maintenance  Display  Module  is  an  qptkm  fiom  die  system 
administrator’s  main  window  and  allows  the  syston  administrate’  to  taile  the  KBMLS  system  to 
interpret  and  sanitize  message  data  accurately.  From  selections  the  user  can  modify  the  various 
support  tables.  File  Maintenance  provides  the  support  to  modify  information  used  to  direct  the 
sanitization  rules.  The  selectable  tables  include  dte  Area  Definition,  Cover  Characteristics, 
Deletion  Table,  Replacement  Table,  Message  Tenqilates,  and  Addressee  Table.  Details  on  each 
of  the  tables  is  documented  in  the  sections  that  follow. 

•  Area  Definition  -  Area  Definition  Table  allows  the  system  administrator  to  specify  a  list  of 
Areas  of  Interest  (AOIs)  for  the  given  site  missions.  Fran  this  list,  it  is  determined  if  an 
incoming  message  is  within  an  AOI  and  sanitization  processing  should  cemtinue. 

•  Cover  Characteristics  -  Cover  Characteristics  Review  allows  the  system  administrator  to 
record  a  list  of  available  covers  and  their  associated  specification.  This  information  is  used 
to  provide  plausible  and  reasonable  cover  alternatives  when  sanitizing  data. 

•  Deletion  Table  -  Deletion  Table  Review  window  allows  the  system  administrator  to 
specify  phrases  that  should  be  deleted  fiom  outgoing  message  product  The  deletion  table 
phrases  are  grouped  by  classification  downgrading  categories.  The  selectable 
classifications  are  Hi  to  Low,  Low  to  Ext,  and  Low  to  Gen.  The  user  can  add  a  new 
phrase  or  modify  an  existing  phrase. 

•  Replacement  Table  -  Replacement  Table  Review  window  allows  the  system  administrator 
to  specify  phrases  that  should  be  replaced  with  a  different  phrase  in  outgoing  message 
products.  The  replacement  table  phrases  are  grouped  by  classification  downgrading 
categories.  The  selectable  classifications  are  Hi  to  Low,  Low  to  Ext,  and  Low  to  Gen. 
Regardless  of  which  classification  is  chosen,  the  Replacement  Table  Review  window  is 


36 


displayed.  The  user  can  add  a  new  phrase  set  or  modify  an  existing  phrase  set  A  (rfirase 
set  consists  of  the  Search  Phrase  applied  to  the  input  message  and  a  Replacement  I%rase 
inserted  in  the  output  message  product 

•  Message  Templates  -  Message  Template  Review  allows  die  system  administrate^’  to  create 
a  list  of  output  message  templates.  From  this  list  the  analyst  is  allowed  to  choose  a 
desired  format  fen*  the  released  sanitized  message  output  products.  The  user  can  add  a  new 
message  template  format  <x  edit  an  existing  format  from  the  Message  Template  List 

•  Addressee  Table  -  Addressee  Table  Review  window  which  allows  the  system 
administrator  to  specify  a  list  of  addressees  that  are  acceptable  for  message  release.  This 
list  is  used  by  the  software  to  determine  if  an  input  message  is  of  interest  The  user  can 
add  a  new  addressee  or  edit  an  existing  addressee  from  the  Addressee  List 

4.4.3  Executive  Control  Component  Module  Descriptions 

The  Executive  Control  Component  is  divided  into  two  subcomponents;  The  Security 
Control  Subcomponent  and  the  System  Control  Subcomponent  The  Security  Control 
subcomponent  provides  mandatory  and  discretionary  access  controls,  user  login  authentication, 
security  audit  trail,  screen  sensitive  labels,  and  maintenance  and  review  functions.  The  System 
Control  subcomponent  controls  the  startup  and  shutdown  of  KBMLS,  along  with  managing  the 
message  logs  and  system  history  logs. 

4.4.3. 1  Security  Control  Subcomponent 

The  modules  which  ccxnprise  the  Security  Control  subcomponent  are  depicted  in  Figure 
4.4.3. 1.  They  are:  the  Login  nxxiule  which  provides  mandatory  and  discretionary  access  controls, 
and  user  login  authentication;  the  Security  Logger  Module  which  receives  security  related  logging 
event  messages  and  maintains  security  audit  tr^;  the  Security  Banner  Module  which  provides 
screen  sensitive  labels;  and  the  Security  Display  Module  which  provides  the  security  manager  with 
maintenance  and  review  functions. 

The  Security  Display  module  and  its  associated  displays  appear  when  a  valid  user  id  and 
password  have  been  entered.  The  bar  across  the  top  of  the  window  displays  the  system 
classification.  The  second  bar  under  the  classification  bar  is  the  main  menu  bar  and  defines  the 
options  available  to  the  security  manager.  They  are: 

•  USER  TABLE  option  allows  the  security  manager  to  add,  delete,  or  modify  KBMLS  user 
accounts. 

•  SECURITY  REVIEW  option  from  the  security  manager's  main  window  allows  the  review 
of  the  Security  Audit  Trail  Log  (SATL). 
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Hgure  4.4.3. 1  Security  Control  Subcranponent  Modules 


4.4.3.2  System  Control  Subcomponent 

The  modules  which  comprise  the  System  Control  Subcomptment  are  depicted  in  Hgure 
4.4. 3.2.  They  are:  the  System  Control  Module  which  controls  the  startup  and  ^utdown  of 
KBMLS;  the  Logger  Module  which  manages  the  message  logs  and  system  history  logs;  the 
System  Administrator  Display  Module  which  provides  the  system  administrator  with  access  to 
logs,  system  ctxitrol  functions,  and  maintenance  functicms;  and  the  Analyst  Display  Module  which 
provides  the  analyst  with  access  to  Sanitization  Case  Folders. 

The  System  Administrator  Display  Module  is  activated  when  a  system  administrator  enters 
their  user  id  and  password.  A  main  menu  bar  defines  the  options  available  to  the  system 
administrator,  lliose  options  are: 

•  SYSTEM  CTRL  cation  allows  the  system  administrator  to  start  and  stop  the  automatic 
sanitization  processing  on  incoming  message  data.  In  addition,  this  optitm  permits  the 
system  administrator  to  monitor  the  KBMLS  software  by  reviewing  which  software 
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processes  are  running.  There  are  dote  available  selections  imder  this  option:  Sanitization 
Startup,  Sanitization  Shutdown,  and  Syston  Nfonitor. 


Figure  4.4.2.2  System  Control  Subcomponent  Modules 


•  LOG  REVIEW  cation  allows  the  system  administrator  to  review  the  set  of  KBMLS  logs. 
The  history  log,  input  message  log,  and  ou^ut  message  log  are  the  reviewaUe  logs. 

•  MAINTENANCE  option  from  the  system  administrator’s  main  window  allows  the  system 
administrator  to  tailor  the  KBMLS  system  to  interpret  and  sanitize  message  data 
acourately.  The  allowable  user  selections  are:  Table  Maintenance,  Grammar  Maintenance, 
and  KB  Mainteruuice.  From  these  selections  the  user  can  modify  the  various  support 
tables,  modify  and  enable  input  message  grammars,  and  maintain  knowledge  base  rule 
sets.  From  this  option  the  system  administrator  initializes  and  critiques  KBMLS  tables  and 
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files  for  die  automatic  sanitization  {Hocessing  tolerations. 

.  SYSTEM  ADMINISTRATOR  LOGOin*  AND  SHUTDOWN  lotion  on  the  system 
administrator  ™in  mmu  bar  closes  the  system  administrator’s  window  ot  shuts  down  the 
KBMLS  software. 

The  Analyst  Dio>lay  Module  is  activated  «4ien  the  nde  associated  with  the  valid  user 
name  and  passw^  is  an  analyst  The  main  functitm  provided  to  the  analyst  is  the  review  of 
sanitization  case  foldos.  Access  to  SCFs  is  accoao>lished  through  die  SCF  Review  <o>tion.  Tht 
Module  supports  the  analyst  in  selecting  one  of  four  types  of  SCF  reviews:  releasable  SCFs, 
sanitized  SCFs,  conditional  SCFs  and  browse  SCFs  by  unit  name.  After  selection,  the  Analyst 
Display  Module  activates  the  SCF  Review  Display  Module.  The  Analyst  Display  Module  also 
provides  access  to  the  message  logs. 

4.4.4  Global  Utilities  Component  Module  Descriptions 

The  Global  Utilities  Component  is  con^sed  of  three  separate  callable  libraries  of  routines 
which  provide  interfaces  to  networks,  interprocess  communications,  and  windows.  They  are; 
Display  Utilities,  External  Utilities,  and  System  Utilities. 

4.5  Overview  of  KBMLS  Operations. 

KBMLS  operations  are  divided  into  three  stages  of  operation.  They  are  Startup/Login, 
Automatic  Processing,  and  Interactive  Processing.  The  following  describes  the  processing  at  each 
stage  of  operations. 

4.5. 1  KBMLS  Startup  and  Login 

Initially,  the  KBMLS  software  is  booted  by  turning  on  the  PC  hardware.  Once  booted, 
the  user  types  “RADC’  and  logs  into  the  KBMLS  system  using  the  KBMLS  account  name.  The 
KBMLS  Login  pronqtt  will  then  be  displayed.  A  user  enters  an  existing  KBMLS  user  id  and 
password  to  execute  the  associated  KBMLS  role.  Figure  4.5.1  depicts  the  process  flow. 

4.5.2  KBMLS  Interactive  Processing 

There  are  three  distinct  roles  in  the  KBMLS  system.  They  are;  the  secuiiQr  manager, 
the  system  administrator,  an  the  analyst  The  security  manager  role  is  responsible  for  maintaining 
the  KBMLS  login  table  and  reviewing  the  S  ATL.  The  system  administrator  capabilities  include 
starting  and  stopping  the  automatic  sanitization  software,  reviewing  history  logs,  input  logs,  and 
output  logs,  maintaining  the  knowledge  base  rale  files,  grammar  files,  and  all  table  maintenance 
functions.  The  analyst  can  access,  modify,  and  review  SCF’s,  and  review  the  input  and  output 
message  logs,  and  release  output  products. 


40 


4.S.3  KBMLS  Automatic  Flow 

The  KBMLS  prototype  accepts  foimatted  message  input  on  a  standard  UNIX  Inter 
Process  COTimunication  (Q^  queue,  as  depicted  in  Figure  4.5.3.  Using  user  defined  grammar 
definiticMis,  the  data  translator  process  parses  the  incoming  message  and  extracts  the  message 
information  into  a  record  structure.  The  original  message  and  the  extracted  information  are 
stored  in  a  sanitization  case  folder  (SCF)  and  written  to  a  database.  The  data  translatm*  sends  a 
message  to  the  pre-sanitizer  with  the  key  to  access  the  new  SCF  to  be  processed.  The  pre¬ 
sanitizer  uses  the  addressee,  area,  and  cover  tables  in  conjunction  with  the  KES  rules  file  to 
determine  if  and  how  the  incoming  message  can  be  sanitized.  The  pre-sanitizer  marks  a  SCF 
category  as  sanitizable,  releasable,  or  denied.  If  the  SCF  is  of  category  denied,  the  message  is  not 
be  sanitized.  If  the  SCF  is  sanitizeable  or  releasable,  a  message  is  sent  to  the  sanitizer  with  the 
key  identifying  the  SCF,  the  sanitization  instruction  set  to  use,  and  the  template  of  the  output 
product  The  sanitizer  uses  the  message  template  table  to  get  the  output  product  template  and 
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wiUfiU  the  temidaielDBywonbwidiiiilbnnatkio  that  wisextncied  The  semtiaer 

then  uses  the  saiiitizatk)n  instnictioiis,  detetkn  and  iq)Uoeniem  tabl^  to  peffofm  the  actual 
sanitiatinn  <rf  the  message. 


Figure  4.5.3  KBMLS  Automatic  Flow 

5.  PRELIMINARY  TESTING/FEASroiUTY  DEMONSTRATION  RESULTS 

5.1  General 

The  Software  Testing  demonstrated  the  use  of  AI  techniques  to  implement  sanitization 
mediods  and  procedures.  Preliminary  tests  on  a  Computer  Software  Configuratimi  Item  (CSCI) 
identified  as  the  Knowledge  Base  Multi-level  Secure  (KBMLS)  Demonstration  System  were 
conducted  with  Government  personnel  present  The  following  subsections  summarize  the  testing. 

5.2  KBMLS  Test  Descriptions 
The  formal  tests  covered  were: 

1.  Security  Manager  Operation  Test  (SecMgr) 

2.  System  Administrator  Operation  Test  (SystAdm) 
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3.  Message  Input  (Msgbi) 

4.  System  Analyst  (SystAnalyst) 

5.  Systnn  Message  ftocessing  (MsgProc) 

6.  System  Audit  Logs  (AuditLogs) 

7.  Syston  Shutdown  (SysShut) 

5.2.1  Security  Manager  Operational  Test  (SecMgr) 

The  security  manager  (^>erational  test  cases  verified  the  (q)aations<tf  the  KBMLS  security 
manager  to  create  and  maintain  tlw  user  accounts  and  review  security  logged  information.  The 
purpose  of  this  test  was  to  verify: 

•  a  user  can  login  as  security  manager  using  an  established  account 

•  the  security  manager  can  review  user  actxmnts 

•  the  security  manager  can  add  user  accounts 

•  the  security  manager  can  delete  user  accounts 

•  the  security  manager  can  modify  user  passwords 

•  the  security  manager  can  review  security  log  infmmation 

•  the  security  manager  can  logout 

5.2.2  System  Administrator  Operational  Test  (SystAdm) 

The  system  administrator  operational  test  cases  verified  the  operations  of  the  KBMLS 
systems  administrator.  The  purpose  of  this  test  was  to  verify: 

•  the  user  can  logon  as  a  system  administratcn’ 

•  the  system  administrator  can  update  the  area  table 

•  the  system  administrator  can  update  the  cover  characteristic  table 

•  the  system  administrator  can  specify  the  sanitization  criteria  using  wildcard  and  keyword 
phases  for  message  data  deletion  and  replacement  criteria  tables 

•  the  system  administrator  can  update  the  message  template  table 

•  the  system  administratOT  can  update  the  addressee  table 

•  the  system  administrate^’  can  maintain  the  data  translation  grammars 

•  the  system  administrator  can  update  the  knowledge  based  rules  files 

•  the  system  administrator  can  logout  of  KBMLS 

5.2.3  Message  Input  (Msgin) 

The  message  input  test  cases  verified  the  message  input  function  of  the  KBMLS. 

Messages  were  sent  firem  an  independent  machine  to  the  KBMLS  host  machine  to  be  translated 
and  sanitized.  The  purpose  of  this  test  was  to  verify: 

•  formatted  messages  can  be  sent  to  the  KBMLS 
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•  formatted  messages  can  originate  on  an  independent  machine. 

•  messages  input  vrill  be  processed  the  dm  translator  and  sanitizer  processes 

5.2.4  System  Analyst  (SystAnalyst) 

The  System  Analyst  test  cases  verified  the  ability  of  the  KBMLS  analyst  to  review  the 
sanitized  messages,  the  sanitization  case  fdder  information,  and  release  ouqnit  products  to  an 
independent  machine.  The  purpose  of  diis  test  was  to  verify: 

•  messages  received  by  KBMLS  can  be  reviewed 

•  the  sanitized  output  product  can  be  reviewed  and  modified. 

•  the  summary  of  infemnation  extracted  fiom  the  message  can  be  reviewed. 

•  the  justification  for  the  message  sanitization  can  be  determined. 

•  the  sanitization  output  product  can  be  released. 

•  the  sanitization  case  foMer  can  be  examined  in  a  logical  ordering. 

5.2.5  System  Message  Processing  (MsgProc) 

The  Operational/Maintenance  Mode  test  cases  illustrated  all  the  KBMLS  functionality 
available  to  the  various  users  during  normal  operations.  Many  of  the  test  procedures  were  shown 
more  than  once  and  were  tested  in  the  Initialization  Mode  test  The  purpose  of  this  test  was  to 
verify: 

«  Table  modifications  can  be  made  to  alter  the  outcome  of  sanitization  processing  and 
SCF’s  can  be  resubmitted  for  sanitization. 

•  Rules  can  be  modified  to  alter  the  outcome  of  sanitization  processing  and  SCP’s  can  be 
resubmitted  for  sanitization. 

•  The  message  format  grammars  can  be  altered  and  recompiled  to  change  the  way  an  input 
message  is  translated  and  a  message  already  received  may  be  retranslated. 

5.2.6  System  Audit  Logs  (AuditLogs) 

The  System  Audit  Logs  test  cases  verified  the  ability  of  the  KBMLS  to  record  a  history  of 
user  events  and  record  account  information  and  security  events.  The  input  and  ou^ut  logs  were 
used  to  keep  record  of  the  messages  received  by  and  the  messages  relea^  from  the  KBMLS 
system.  The  purpose  of  this  test  was  to  verify: 

•  messages  received  by  KBMLS  are  stexed  in  logs 

•  messages  released  by  KBMLS  are  stored  in  logs 

•  all  user  account  information  and  security  events  are  maintained. 

•  all  system  process  actions  of  significance  are  maintained. 
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S.2.7  System  Shutdown  (SysShut) 


The  System  Shutdown  test  cases  verified  the  ability  of  the  KBMLS  processes  to  pr(^>eiiy 
terminate  and  the  ability  of  the  UNIX  system  to  properly  be  shutdown.  The  purpose  of  this  test 
was  to  verify: 

•  the  KBMLS  system  can  stop  all  processes  and  terminate. 

•  the  UNIX  system  can  properly  shutdown. 

5.3  Test  Preparations 

The  KBMLS  Hardware  architecture  for  the  demonstration  system  was  a  single  processca^ 
architecture  with  external  interfaces  as  shown  in  Hgure  4.2  in  Section  4.2.  The  architecture  was 
designed  to  meet  security  requirements.  In  order  to  achieve  these  requirements  a  prepackaged 
tempest  hardware  suite  was  acquired  from  DataWatch  Corporation.  The  following  is  a  list  of 
Hardware  characteristics  that  constitute  the  KBMLS  hardware  architecture: 

DATAWATCH  386/25  TEMPEST  WORKSTATION 
Unit  Description:  80386  25  MHZ  Processor 

16  MB  Total  System  RAM 

80387  Coprocessor 

SCSI  Controller 

160  MB  Removable  Hard  Drive 

100  MB  Removable  Hard  Drive 

1.2  MB  Floppy  Drive 

1.4  MB  Flojpy  Drive 

2  Serial/1  l4^el  Adapter 

VGA  Adapter  and  VMM  VGA  Color  Monitor 

DataWatch  Tempest  Logitech  Mouse 

Standard  Keyboard. 

TEMTEK  EXIOOOT  Dot  Matrix  Tempest  Printer 
Unit  Description:  Dot  Matrix  Printer 

Shielded  Parallel  9ft  Cable. 


5.4  KBMLS  Test  Results 

KBMLS  testing  extended  over  a  period  of  three  years.  The  following  documents  each 

test. 
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S.4.1  lYeliiniiiary  Testing:  August  IS,  1990 


The  KBMLS  Pteliminary  Test  was  condiK^ted  during  the  week  of  August  IS.  1990  at  the 
FSCs  facility.  This  test  activity  satisfied  the  Preliminary  Acceptance  Testing  requirement  of  the 
KBMLS  Development  Contract  and  was  wimessed  by  Government  reivesentatives  frcHn  Rome 
Laboratory.  All  pre-test  activities  were  conducted  by  the  developing  ccmtractcM’  prior  to  the 
execution  of  the  test.  Debriefing,  data  reduction  and  analysis  of  the  test  results  were  conducted 
immediately  after  the  completion  of  the  test  The  prototype  system  passed  all  tests. 

5.4.2  Preliminary  Testing:  February  18, 1993 

The  KBMLS  Preliminary  Test  was  conducted  at  FSCs  facility  during  the  week  of 
February  18, 1993  and  was  witnessed  by  Government  representatives  fix)m  Rome  Laboratory. 
This  test  activity  concluded  the  Preliminary  Acceptance  Testing  requirement  of  the  KBMLS 
Development  Contract.  All  pre-test  activities  were  conducted  by  the  developing  contractor  prior 
to  the  execution  of  the  test  Debriefing,  data  reduction  and  analysis  of  the  test  results  were 
conducted  immediately  after  the  corr^letion  of  the  test  Tests  which  were  incomplete  were 
deferred  until  Final  Acceptance  Testing. 

5.4.3  Final  Acceptance  Testing:  March  26, 1993 

The  KBMLS  Final  Acceptance  Test  was  conducted  during  the  week  of  March  26, 1993  at 
the  Government's  facility,  at  Rome  Laboratory.  The  test  was  wimessed  by  Government 
representatives  from  Rome  Laboratory.  This  test  activity  satisfied  the  Find  Acceptance  Testing 
requirement  of  the  KBMLS  Development  Contract.  All  pre-test  activities  were  conducted  by  the 
developing  contractor  prior  to  the  execution  of  the  test.  This  included  interfacing  to  computer 
equipment  within  the  Government  Facility  which  emulated  the  IDHS  computer  (High  Side)  and 
the  USAFE  GUARD  system.  The  ccmtiguration  is  depicted  in  Figure  4.2,  in  Section  4.2.  All 
preliminary  tests  which  were  iix;on:^)lete  were  rerun  and  were  successful.  KBMLS  successfully 
demonstrated  the  capability  to  accepted  multiple  messages  frtxn  the  system  high  netwoik,  parse 
messages,  invoke  the  sanitization  rule  sets,  sanitize  and  format  the  information  into  a  TUM,  and 
release  the  sanitized  message  to  the  USAFE  GUARD  system. 

6.  IMPLEMENTATION  PLAN 

The  implementation  plan  centers  around  both  short  term  and  long  term  operational  goals. 
The  short  term  goal  is  to  demonstrate  the  feasibility  of  using  AI  techniques  to  assist  intelligence 
analysts  in  performing  sanitization  by  preparing  automatically  sanitized  message  traffic  for  manual 
review  by  an  analyst.  The  long  term  goal  is  to  relieve  the  analyst  from  near  real  time  reporting 
responsibilities  by  using  AI  techniques  to  automatically  sanitize  and  disseminate  a  subset  of 
message  traffic  which  relates  to  changes  in  the  Order-of-Battle  (OB)  data  base. 
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6.1  Concept  of  KBMLS  Operations 


The  Primary  Mission  of  KBMLS  is  to  serve  as  a  con^nent  of  the  USAFE  Guard  System. 
It  supp(»ts  the  Force  Assessment  Branch  Analyst  by  assisting  in  the  sanitization  of  sensitive 
intelligence  infcmnation  and  the  generation  of  sanitized  products  fOT  dissemination.  KBMLS 
assists  the  analyst  by  providing: 

•  Automatic  identification  of  information  required  by  wing  commanders  and/OT  other 
tactical  decision  makers 

•  Automatic  determination  that  information  can  ot  cannot  be  sanitized 

•  Automatic  selection  and  application  of  aj^nopriate  sanitization  procedures 

•  Automatic  generadcm  (or  review)  of  sanitized  product 

•  User  friendly  interface  for  analyst  to  modify  system  operational  parameters. 

The  KBMLS  accomplishes  this  by  providing  necessary  communications  interfaces, 
sanitization  decisitxi  support  functions,  and  a  man-machine  interface  to  permit  the  analyst  to 
access  and  review  sanitized  information.  The  KBMLS  software  can  be  changed  in  the  field  to 
reflect  changes  in  the  policies  and  procedures  mandated  by  cognizant  authority  significantly 
reducing  life  cycle  maintenance  costs. 

The  KBMLS  Sanitization  software  is  capable  of  residing  on  the  same  computer  suite  as 
the  TS/Sa  host  or  the  USAFE  GUARD.  These  TS/SQ  host,  USAFE  GUARD,  and  KBMLS 
con^uters  operate  at  the  "system  high"  level.  (In  other  words,  all  data  in  the  system  are 
protected  as  TS/SQ  until  a  perstm  determines  or  approves  the  actual  classification  of  the 
sanitized  data.)  KBMLS  will  communicate  with  its  collocated  high  host  and  GUARD  via  a 
system  high  local  area  network  called  the  USAFE  Theater  Air  Intelligence  Network  Local  Area 
Network  (UTAIN  LAN).  TS/SQ  access  will  be  required  for  persons  to  have  physical  access  to 
the  UTAIN  LAN,  the  Guard,  TS/SQ  host,  or  KBNQ.S  computers. 


m.  CONCLUSIONS 


1.  CLOSING  SUMMARY 

The  Knowledge  Based  Multi-Level  Secure  Network  Technology  (KBMLSNT)  project 
began  with  an  operational  requirement,  fitom  the  COIC/TFC,  to  investigate  ways  of  increasing  the 
timeliness  of  Chder-of-Battle  updates  to  wing  commanders.  This  operational  requirement 
translated  into  the  goal  of  applying  artificial  intelligence  techniques  to  the  problem  of  sanitizing 
sensitive  information  for  dissonination  to  wing  commanders. 

FSC  began  by  initiating  a  knowledge  acquisition  effort  at  the  COIC  and  TFC  sites.  These 
sites  provided  the  information  needed  to  define  a  sanitizatimi  model  The  model  described  the 
current  manual  process  involved  with  saiutization  and  where  artificial  intelligence  techniques  such 
as  expert  systems,  knowledge  based  systems,  and  natural  language  {vocessors  could  be  applied. 

Hardware  and  software  requirements  followed  the  Air  Force's  standards  for  developing 
con^uter  systems  for  processing  classified  infcmnation.  The  hardware  was  a  TEMPEST 
386/25Mh2  Workstation  with  a  UNIX  System  V3.2  operating  system.  The  KBMLS  software 
was  written  in  C  and  Ada  and  contains  a  COTS  expert  system  shell  called  KES.  FSC  conducted  a 
survey  of  expert  system  shells  and  natural  language  parsers  which  would  meet  operational 
requirements.  To  support  contract  requirements,  the  software  developed  by  FSC  and  all  COTS 
packages  had  to  be  portable  to  other  workstations. 

The  software  developed  by  FSC,  adheres  to  the  open  system  architecture  principles  of 
portability,  availability,  scalability,  and  inter(^)erability.  The  user  interface  was  develop^  within 
X-Windows/  Motif  standards.  The  external  network  interface  communicates  using  TCP/IP  and 
will  easily  transition  to  GOSIP  network  protocols  in  the  future.  The  software  is  divided  into  four 
sections;  Data  Translation,  Sanatization,  Executive  Control,  and  Global  Utilities.  Data 
Translation  enables  KBMLS  to  understand  and  process  multiple  message  formats.  Sanitizion 
provides  all  functions  involved  with  authorization  and  sanitization.  Executive  Control  provides 
the  necessary  control  and  security  mechaiusm  for  KBMLS  to  solely  execute  on  a  workstaticm. 

The  Global  Utilities  provides  portability  through  nxxiifications  to  a  few  routines. 

Testing  included  interfacing  KBMLS  to  computer  equipment  within  the  Government 
Facility  which  emulated  the  IDHS  computer  (High  Side)  and  the  USAFE  GUARD  system.  The 
configuration  is  depicted  in  Figure  4.2,  in  Section  4.2.  All  preliminary  tests  were  successful  and 
KBMLS  successfully  demonstrated  the  capability  to  accepted  multiple  messages  fixxn  the  system 
high  network,  parse  messages,  invoke  the  saiutization  rule  sets,  sanitize  and  format  the 
information  into  a  TUM,  and  release  the  sanitized  message  to  the  USAFE  GUARD  system.  Due 
to  time  limitations,  not  all  messages  sets  were  developed  and  tested  to  determine  if  the  rules  were 
con^lete. 
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The  benefits  of  the  KBMLS  system  are  many.  It  provides  a  mechanism  to  retain  ccxporate 
knowledge  relating  to  sanitization  and  at  the  same  time  assist  in  the  training  of  new  analysts.  The 
KBMLS  system  has  the  potential  to  increase  the  flow  of  critical  information  to  wing  commanders 
and  establish  ccmsistency  in  reporting  critical  events.  It  has  the  potential  to  reduce  or  eliminate 
future  security  breaches.  Examples  of  KBMLS's  overall  benefit  as  it  relates  to  Missitm 
Responsiveness,  Operational  Siq>p(nt  at  Site,  and  Growth  /  Flexibility  are; 

•  Mission  Re^xmsiveness  Equipped  with  the  on-site  cq)ability  to  modify  rules 

and  knowledge  as  mission  requirements  change 
provkles  near  real  time  readiness  siqiport  during 
peacetime  and  wartime. 

•  Operational  Support  at  Site  Integration  with  the  existing  Intelligence  Community 

Computer  Architecture  and  conforming  to  Human 
FactOTS  standards  reduces  training  and  technical 
manual  costs.  Use  of  existing  or  future  equipment 
minimizes  spares,  support  equipment  and  preventive 
maintenance  costs. 

•  Growth  /  Flexibility  Portable  to  future  Intelligence  Community  Computer 

Architecture's.  Flexible,  with  on-site  modifications  to 
expand  rules  and  knowledge  to  accommodate  other 
Intelligence  Community  domains. 


Operational  Flexibility  is  a  key  to  mission  responsiveness.  Table  1  describes  a  situation 
and  suggests  how  KBMLS  would  be  adapted  to  meet  the  change. 


Table  1  Examples  of  Operational  Flexibility  as  it  relates  to  Mission  Responsiveness 


As  wings  dq)loy  and  redeploy  in  and  out  of  theater 

Update  sanitization  rules  and  tables  to  account  for  the 
change 

When  changes  to  National,  Service,  and  Theater  level 
sanitization  policies  occur 

Modify  the  sensitivity  rules  and  sanitization  deletion 
and  rq)lacement  criteria  tables  to  reflect  the  change  in 

POliCY 

As  the  threat  changes 

Activate  desired  rule  sets,  correqxMiding  to  DEFCON 
levels,  for  automated  sanitization  mocessing 

Oxasionally,  incoming  message  fcxmats  change 

Modify  input  message  parsing  grammars 

Conversely,  as  outgoing  sanitized  message  fcxmats 
change 

Modify  the  Outgoing  Message  Template  taUe 

As  units  are  deployed  (X  redeployed  altering  the  Order 
of  Battle 

Modify  the  need  rules  to  specify  q)ecific  interest  in  a 
unit  as  it  relates  a  list  of  potential  addressees 

49 


2. 


FUTURE  EVOLUTION  OF  KBMLS 


Site  acceptance  and  accreditation  of  both  short  term  and  long  term  goals  are  dependent  on 
an  evolutionary  approach.  Figure  1  depicts  the  potential  evolution.  Today,  analysts  are  wholly 
responsible  for  sanitizing  inc(»iung  message  traffic  and  a  senior  officer  is  the  reviewAelease 
authority.  It  is  envisioned  that  in  the  first  implementation  and  deployment  of  KBMLS,  the  syste  i 
would  auttxnatically  sanitize  and  present  to  the  analyst  the  sanitized  information  for  verification  " 


Figure  1  KBMLS  Evolution 

Statistics  would  be  gathered  on  the  performance  and  accuracy  of  the  KBMLS  system.  The 
system  would  be  enhanced  to  account  for  known  deficiencies.  The  second  implementation  and 
deployment  of  the  KBMLS  system  would  relieve  the  analyst  of  the  responsibility  to  sanitize 
incoming  data.  Only  the  senior  officer  would  remain  within  the  loop,  providing  review/release 
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authority.  Lack  of  senkM*  t^cer  denial  would  pave  the  way  to  the  final  implementatkMi.  The  final 
implementation  and  deployment  would  eliminate  the  senior  t^ficer  from  die  sanitization  process 
and  the  KBMLS  system  would  automatically  sanitize  and  disseminate  information  to  air  wing 
commanders. 
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AFB 

AFMC 

AI 

AOB 

C2I 

CDRL 

COIC 

COMINT 

csa 

DEFCON 

DoD 

ECM 

FA 

FIRE 

FSC 

FTP 

I&W 

ID 

IMINT 

INTREP 

KBMLS 

KES 

MLS 

MOB 

NATO 

OIs 

PC 

RL 


Air  Force  Base 
Air  Force  Material  Command 
Artificial  Intdligence 
Air  Order  of  Battle 

Command,  Omtiol  and  IntelligeiK:e 
Contract  Deliverable  Requirements  List 
Combat  Operations  Intelligence  Center 
Communications  Intelligence 
Computer  Software  Configuration  Item 

Defense  Condition 
Department  of  Defense 

Electronic  Counter  Measures 

Force  Assessment  Branch 
Fused  Intelligence  Report  to  Europe 
Fuentez  Systems  Concepts,  Inc. 

Hie  Transfer  Protocol 

Indications  and  Warning 

Identification 

Imagery  Intelligence 

Intelligence  Report 

Knowledge  Based  Multi-Level  Secure 

Knowledge  Expert  System 

Multi-Level  Secure 
Missile-Order-of-battle 

North  American  Treaty  Organization 

Operating  Instructions 

Personal  Computer 

Rome  Laboratory 


SAM 

SAMINTREP 


Surface-to-Air 
SAM  Intelligence  Report 


SAIL 

Security  Audit  Triul  Log 

SCF 

Sanitization  Case  folder 

sa 

Soisitive  Compartmented  Information 

SCO 

Santa  Cruz  Operations,  Inc 

SDD 

Software  Description  Document 

SIGINT 

Signal  Intelligence 

SOW 

Statement  of  Work 

STD 

Scrftware  Test  Description 

TAN 

Target  Air  Nomination 

TFC 

Tactical  Fusion  Center 

THN 

TFC  Intelligence  Input  to  NATO 

TWHN 

TFC  Wartime  Intelligence  Input  to  NATO 

U.S. 

United  States 

USAF 

United  States  Air  Force 

USAFE 

United  States  Air  Force  Headquarters  in  Europe 

USAFINTELL 

United  States  Air  Force  Intelligence 

USEUCOM 

United  States  European  Command 

VA 

Virginia 

VGA 

Video  Gr^hics  Adapter 
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APPENDIX  A 


EXPERT  SYSTEM  VENDORS  AND  FEATURES 


ALEX  1.1; 

Harris  A  Hall  AsaociaUss 
P.O.  Box  1900 
Pott  Angeles,  Wash.  98362 
(206)457-4907 

INTraijnENrFJmMPn  FR;  $490 
IntelligenceWare.  Inc. 

9800  S.  Sepulveda  Blvd. 

Los  Angeles,  CA  9004S 
(213)417-8896 

COSMIC  CLIPS  4,2;  $250 
University  of  Georgia 
382  E.  Broad  St 
Athens,  GA.  30602 
(404)542-3265 

CxPERT3.0i  $795 
Software  Hus 
1652  Albermarle  Dr. 

Ciofton,  MD.  21114 
(301)261-0264 

ESPADYISOR-.2;.$6S5 
ESP  FRAME  ENGINE:  $695 
Expert  Systems  International 
1700  Walnut  Sl 
Philadelphia.  PA.  19103 
(215)735-8510 

EXSYS  PROFESSIONAL:  S2J00 
EXSYS  Inc. 

P.O.  Box  11247 
Albuquerque,  NM.  87192 
(505)256-8356 

1st  CLASS  HT:  $2,425 

1st  CLASS  Expert  Systems  Inc. 

526  Boston  Post  Rd. 

Wayland.  MASS.  01778 
(508)358-7722 


Runs  in  Smalltalk  envitonmenL  Allows  pcogtanuiiers  to  devdop 
object-oriented  expert  systems. 


An  expert  system  development  environment  that  comNoes  rul^ 
frames,  relational  datahaya  md  hypertext  It  siqtports  a  variety  of 
AI  techniques. 


Machine-inttependent;  runs  under  any  complete  C  compiler.  Made 
available  for  reuse  under  NASA's  Tedinoh)^  Utilization  Program. 


Object  code  version  is  available  for  the  IBM  PC  and  compatibles. 
Source  code  version  is  written  in  C  and  can  be  compiled  on  any 
machine.  Object  code  version  runs  under  MS-DOS. 


ESP  Frame  Engine  is  a  frame-based  system  that  supports  forward 
and  backward-chaining  rules.  Advisor-2  is  an  enhanced  rule- 
based  system  whkh  inovides  direct  access  to  external  programs  and 
languages.  Runs  under  MS-DOS,  VMS  and  UNIX. 


EXSYS  is  a  tool  fw  development  of  probabilistic  rule  based  expert 
systems  and  provides  flexible  means  to  combine  confidence  factors 
and  direct  access  external  programs  and  languages.  Runs  under 
VMS.  UNIX,  MS-DOS  and  OS/2. 


A  combination  of  a  forward  and  backward  chaining  expert  system 
shell,  code  generator,  graphics  capture  and  di^lay  utilities  and 
database  interface.  Runs  under  MS-DOS  and  VMS. 
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GOLDWORKSIL  M.900 
Gold  Hill  Ompulen  Inc. 
26  Landsdowne  Sl 
Cambridge.  MASS.  Q2139 
(617)621-3300 


Hybrid  shell  whkli  combines  rales,  frames.  Md  obfoct  orieoied 
ITOgiamming  with  gcq)hical  interfaces.  Runs  under  a  wiety  of 
operating  systems. 


GURU; 

Micro  Dtta  Base  Systems  Inc. 
P.O.Box248 


Lafayette,  IND.  47902 
(317)463-2581 


Expert  envirooment  for  business  applicadoo  devdopment  with  easy 
access  to  databases,  qiieadsheet  and  word  processing  programs. 
Runs  under  MS-DOS.  OS/2  Sun.  UNIX  »d  VMS. 


HUMBLE  2.0:  S39S 
Xerox  Special  Info.  Systems 
250  N.  Halstead  St. 
Pasadena,  CA.  91107 
(818)351-2351 


Available  for  many  Xerox  machines  Macintosh.  Sun  workstations, 
HP  9000  series.  Apollo  3000  aitd  4000  series  and  some  Tektronix 
machines.  Runs  in  Smalltalk/80  environmem. 


INSTANT  EXPERT  PLUS:  S498 
Human  Intellect  Systems 
1670  S.  /kmphlett  Blvd.  #326 
San  Mateo.  CA.  94402 
(415)571-5959 


Instam  Expert  Plus  combines  rales  and  grqthics  to  create  expert 
systems  applications.  Uses  forward  and  backward  chaining  and 
mixed  logic.  Runs  under  MS-DOS  and  Macintosh  OS. 


KPS  3.6:  S1.495  A  large-capacity  system.  KDS  3jS  uses  inductive  reasoning  to 

KDSCotp.  produce  rules  facts.  Runs  under  MS-DOS. 

934  Hunter  Rd. 

Wilmette.  ILL.  60091 
(312)251-2621 


KFR;  sonno.$3onno 

IntelliCorp 

1975  El  Camino  Real 

Mountain  View,  CA.  94040 

(415)965-5500 


LISP-based  development  tool  for  creating  aixl  delivering  large, 
complex,  knowledge  based  applications.  Runs  under  a  variety  of 
operating  systems  and  on  a  variety  of  machines. 


KES:  S4.000 
Software  A&E  Inc. 

1600  Wilson  Blvd.  #500 
Arlington.  VA.  22209 
(703)276-7910 


Object  oriented  expert  system  shell  designed  to  link  with  C  code 
modules.  Written  in  C.  Runs  under  a  large  variety  of  operating 
systems  and  machines. 


KNOWLEDOEPRO-  !M95 
Knowledge  Gardmi  Inc. 

473A  Malden  Bridge  Rd  RD2 
Nassau,  N.Y.  12123 
(518)766-3000 


KnowledgePro  is  a  knowledge  processing  enviroiunent  that 
combines  hypertext,  a  variety  of  AI  techniques  and  conventional 
programming  productivity  tools. 
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LEYEU; 


Infonnation  Builden  Inc. 
1230BiQndway 
NewYo(k,N.Y.  10001 
(212)736-4433 


In  ndditioo  to  an  eqxsrt  aysiera  shell,  LevdS  contam  a  nmnber  of 
direct  icwriie  interfaces  losttnted  databases .  Raas  under  MS- 
DOS.  Macintosh  OS.  VM/CMS.  MVS/TSO  aid  VMS. 


B:  S495 


CAM  Software 
7S0N.  200  West.  Ste.  206 
Ftovo.  Utah  84601 
(801)373-4080 


Expert  system  development  tool  iha  uses  decision  trees  to  capnue 
knowlec^.  Runs  under  MS-DOS. 


M.1:  S3.000 

Cimflex  Tdoxmled^  Corp. 
1810  Emfaaicadeio  Rd. 

Palo  Alto.  CA.  94303 
(415)424-0500 


M.  I  is  available  on  the  IBM  PC/ST/AT  and  true  compaiWes.  It  is 
geared  toward  small,  rule  based  development  projects.  $5000  is  for 
site  license. 


tYKBE:  $31.000 
Artificial  Intelligence  Tech. 
40SawMiURd. 
Hawthorne.  N.Y.  10532 
(914)347-6860 


Available  for  VAX  machines;  runs  under  VMS.  Knowledge 
engineering  environment  designed  to  provide  high  performanoe, 
stable  storage  and  tight  integratioo  with  the  uaa’s  software  tools 
and  methodologies. 


NEXPERT  OBJECT:  $500Q-$80QQ 

Neuron  Data 

444  High  Sl 

Palo  Alto.  CA.  94301 

(415)321-4488 


A  rule  and  d>ject-orienied  sheU.  written  in  C,  with  graphical  inter¬ 
faces.  Fully  cross-compatiUe  with  other  platforms.  Runs  under 
MS-DOS.  UNIX.  VMS  and  the  Macintosh  OS. 


PC  EXPERT  PROFESSIONAL:  $495 
Software  Artistry 
3500  DePaul  Blvd. 

Indiani^lis,  IND.  46286 
(317)876-3042 


PC  Expert  is  developed  for  use  with  Pascal.  Microsoft  C,  Turbo  C. 
JPI  Moduia-2  and  Logitech  Modula-2.  It  contains  an  inference 
engine,  a  |uocedural  language  and  internal  development 
environment 


PERSONAL  CONSULTANT  PLUS  Available  for  IBM  PC/XT/AT  and  compatibles.  Runs  under  MS- 

$2.950  DOS. 

Texas  Instruments  Corp. 

P.O.  Box  1444 
Houston.  TX  77251 
(800)847-2787 


SOCRATES:  $295-8695  Decision  tree  expert  system  designed  for  knowledge-based 

CIM  Solutions  management;  Socrates  is  written  in  C  and  features  context  sensitive 

754  S.  4(X)  East,  Ste.  2(X)  searching.  Runs  under  MS-DOS  and  VMS. 

Orem.  UTAH  84058 
(801)374-5626 
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Allows  (tevekapoieitt  of  apptirjriowiaBorianJsTurtw&iiia^ 
bngusges.  Rius  under  l^-DOS. 


TirennsHBiJ  tno 
Bokshiie  Sofbrare  G>. 

44MMtiaoaSL 
Lyntirook.N.Y.  11563 
(516)59341019 

VP-EXPERT:  S249  Rule  based-expert  system  development  tool  with  liida  to 

Papertmck  Software  Inc.  spreadshems,  datab^.  managers  and  ASCII  files.  Runs  under  MS- 

2830  Ninib  St  DOS. 

Berkeley.  CA  94710 
(415)644-2116 


58 


APPENDIX  B 


DOCUMENT  PARSING  TOOL  VENDORS 

msDsm,  jQOL 

1.  SYCHRONHnCS.INC  NL  BUILDER  (Hyteid  Tool) 

P.O.BOX793 

HANOVER.  MD.  21 1076 

2.  WESWARE,INC.  GOLDEN  RETRIEVER  CText  Search  Tool) 

42  EPPING  STREET 

LOWELL.  MA018S2 

3.  THIRD  EYE  SCXTWARE.  INC  ELEXIR  (Text  Search  Tool) 

surra  170 

S3S  MIDIXEFIELD  ROAD 
MENLO  PARK.  CA  94025 

4.  ENGUSH  KNOWLEDGE  SYSTEMS  JAKE  (Natural  Language  Processor) 

5525  SCOTTS  VALLEY  DR  #22 

scxyrrs  VALLEY.  CA  95066 

5.  DATAMAT  raXT/SEARCH  (Text  Search  Tool) 

VIA  SIMONE  NARTINI 126 

00142  ROMA  (EUR) 

6.  BBN  SYSTEMS  PARLANCE  (Nabiral  Lnguage  Processor) 

AND  TECHNOLOGIES  CX)RP. 

10  MOULTON  STREET 
CAMBRIDGE.  MA  02138 
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MISSION 


OF 

ROME  LABORATORY 


Roma  Laboratory  plans  and  executes  an  interdisciplinary 
program  in  research,  development,  test,  and  technology 
transition  in  support  of  Air  Force  Command,  Control, 
Communications  and  Intelligence  (C3I)  activities  for  all 
Air  Force  platforms.  It  also  executes  selected 
acquisition  programs  in  several  areas  of  expertise. 
Technical  and  engineering  support  within  areas  of 
competence  is  provided  to  ESC  Program  Offices  (POs)  and 
other  ESC  elements  to  perform  effective  acquisition  of 
C3I  systems.  In  addition,  Rome  Laboratory  technology 
supports  other  AFMC  Product  Divisions,  the  Air  Force  user 
community,  and  other  DOO  and  non-DOD  agencies.  Rome 
Laboratory  maintains  technical  competence  and  research 
programs  in  areas  including,  but  not  limited  to, 
communications,  command  and  control,  battle  management, 
intelligence  information  processing,  computational 
sciences  and  software  producibility,  wide  area 
surveillance/sensors,  signal  processing,  solid  state 
sciences,  photonics,  electromagnetic  technology, 
superconductivity,  and  electronic 
reliability/maintainability  and  testability. 


